The Save button is gone, and so is the SaveTarget context that announced it.
Every screen here is a preview of the thing being edited, so a change is already
visible before it is written — a button then asks somebody to confirm what they
can see.
useAutosave debounces a burst into one request. It takes the unsaved state as a
string rather than a flag, so a failed save is not retried on the next render,
and it flushes on unmount so a section change loses nothing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Three changes to the page list.
MENU ITEM, ADDRESS, PAGE TITLE — the order somebody fills them in. The menu item is what you type first
and the address falls out of it, so they sit together. The title is last because it is the one that
usually stays as it is: it is the browser tab and the search result, not anything on the screen.
THE ADDRESS DERIVES FROM THE MENU ITEM, while the two still AGREE.
"Unless it was changed after" needs to know whether it was changed, and there is no such flag in the
database. There does not need to be: an address that still equals what the menu item would produce has
plainly not been given one of its own, and one that differs plainly has.
That distinction is the whole value. Renaming "Collabs" to "Collaborations" moves /collabs, which is
what anybody would expect. Renaming "Exclusive Drops" does NOT move /drops — somebody chose that
address, and every link to it would break silently. The rule tells those apart without being told.
HOME HAS NO ARROWS, rather than two dead ones, and the first movable row cannot climb past it. A
disabled control invites somebody to work out why; there is nothing to work out.
The slug rule is a copy of the server's, and the kind worth having: the alternative is a request per
keystroke to be told what the address will be. It is only ever a suggestion — the server slugifies
again on the way in, so a disagreement produces a tidier address, never a wrong one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The nav already said it: Pages is a section, and the pages are rows under it. Two things, two screens.
The detail panel was showing one screen with a row lit up, which made the list the answer to both
questions.
?section=pages the list — what exists, what it is called, where it lives, in what order
?section=pages&page=4 that page — what is on it
Both addressable, which is why the distinction is a query parameter rather than state.
Pressing PAGES itself now clears `page`. Without that the section row and the row for whichever page
was last open lead to the same screen and there is no way back to the list but the browser's back
button. Scoped exactly like `media`, and for the same reason: a parameter belonging to one section
should not ride along into the others.
The list stops having a selection — selecting a page leaves the screen entirely — so its rows are
plain rows again and the panel no longer reads or writes the URL at all.
Adding a page deliberately does NOT open it. The next thing anybody does is name it, and the name lives
on the list; jumping into the builder would mean coming straight back.
SitePreview is now shared, lifted out of LayoutPanel with the dev-port lookup beside it. Layout passes
the theme it is editing; a page passes nothing and just gets its own page. The builder shows the real
page at its real address today, which is what the blocks will be judged against when they exist.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The section is real, and the nav draws the site's pages as rows beneath it. That is the one place this
admin has a hierarchy and it earns it: a page is a thing you go to, and the list of them is the site.
Drawn whether or not Pages is the open section — hiding the list until you click makes the nav a menu
of menus.
Three kinds of change, saved three different ways, and the split is deliberate. TEXT — a title, a menu
label, an address — is drafted and written by the one Save in the bar, because typing is something
people do halfway and change their minds about. ADDING, DELETING and REORDERING are immediate: each is
a single deliberate gesture with an obvious result, and holding them in a draft would put a list on
screen that does not exist yet, then leave Save to decide what order to apply three kinds of change in.
Only the rows that actually changed are sent, so a save touches what somebody edited and nothing else.
A failed save reloads from the server rather than leaving the typed values on screen, where they would
look saved.
Home's address and delete button are ABSENT, not disabled. A greyed control invites somebody to work
out why they cannot use it; there is nothing to work out, the front page is always `/`.
The two panels share the list through a channel rather than both fetching it. They are siblings and
neither can pass the other a prop, and two fetches means two lists that agree until somebody renames a
page. Selection stays in the URL — `?page=` — because that is addressable and the list is not.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
pastilhasandClaude Opus 5