History panel + undo in the editor (#49) #63
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  steveandClaude Opus 4.8
|
324cf2f5bb |
Address Gadfly review on the history panel
Build image / build-and-push (push) Successful in 15s
The best catch was one I'd have missed: the store already has resetTransient(), a single list of ephemeral editor state, and the new railTab didn't join it — so the public garden page cleared everything except the rail. Rather than adding railTab in two places, the editor page now calls resetTransient() instead of maintaining its own parallel list, which is what let them drift in the first place. The rail auto-switch keyed off a "something is selected" boolean, so it fired on the transition into having a selection and never again. Select a bed, switch to History, select a different bed — the boolean never changed, so the inspector never came forward, breaking the constraint the whole design was built around. Now keyed off the selected ids. Closing the rail cleared the canvas selection regardless of which tab you were on, so dismissing History deselected your bed. Only the inspector is about the selection, so only closing it deselects. describeUndo said "Undone." when the server reported a complete no-op (200 with a null change set, reachable by undoing a creation whose object is already gone). That reports work that didn't happen; it now says so. relativeTime rounded, so 18 hours ago read as "yesterday" and 90 minutes as "2h ago" — rounding up into the next unit reads as a bigger gap than actually elapsed. Floors throughout. Clock skew that puts a just-written entry slightly in the future now reads "just now" rather than falling through the negative. A failed "Load older" was swallowed entirely: the button simply stopped working. It now reports the error, while the top-level alert only takes over when there is nothing on screen at all. changeCountSchema took any number. Counts come from COUNT(*) and can only be non-negative integers, so constraining them makes bad data fail loudly instead of quietly hiding an Undo button (totalChanges gates it) or rendering "1.5 beds changed". Dropped useUndo's unused isPending — the per-change-set outcome already carries it, and per-row is right anyway. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ |
||
|
steveandClaude Opus 4.8
|
4b18ac3b46 |
History panel and undo in the editor (#49)
#48 made every change revertible; this makes that reachable. The bar was that undoing what the agent just did should take one obvious click, not a hunt. Settles the rail-layout question, which is the part #53 and #57 depend on. Four things wanted one strip of screen — inspector, history, journal, chat — so they are tabs in one EditorRail rather than each bolting on its own chrome. That keeps the canvas at one width instead of a different width per panel, and adding the journal or chat later is adding a tab. Two constraints held. Selecting an object still lands you in the inspector with no extra click: the page watches the selection and switches tabs itself, so the rail never becomes something you operate before you can edit. And the canvas stays worth watching while the agent edits it — the rail is a fixed 20rem column that closes completely when nothing needs it. On a phone the same tabs render in the bottom sheet the inspector already lived in. A reverted entry stays in the list, struck through and marked, and the revert appears as its own entry — because that is what it is. Making the original disappear would be rewriting history rather than appending to it, and would leave no way to undo the undo. Conflicts are reported as what actually happened. A 409 from a revert is not a plain failure: it carries the change set that DID apply alongside the entities deliberately left alone, so the message is "2 of 3 changes undone — “North Bed” was edited since, so it was left alone" rather than a generic toast. A bare failure would be a lie about the two that applied; a bare success would hide the one that didn't. Undo is one implementation, not two: useUndo owns the mutation, the per-change- set outcome and the phrasing, and UndoButton renders it. #57's inline undo on an agent turn uses the same hook, so undo behaves identically wherever it appears. The panel says plainly that deleting a whole garden isn't covered and can't be undone, rather than leaving that to be discovered. Closes #49 Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ |