Week 068 — Item UI Rethink

Before the API can be tested, the UI has to be redesigned.

Week of March 9, 2026

Progress

The item UI needed to change before any of the API refactor work could be properly tested. The existing design had accumulated debt — an edit button that was more confusing than helpful, state change buttons that didn't clearly reflect what the current state was, and fields that appeared regardless of relevance.

A design canvas was created to map out the state transitions visually: what shows on load for each state, what changes when the user makes a state selection, what triggers a save, what triggers a cancel. The canvas made two things clear: page load and state transitions share the same display logic and should use the same code path, and validation should be driven by visibility rather than state — if a field is visible, it's relevant; if it's hidden, it doesn't need to validate.

The two key design decisions:

No edit button. Editing is live. When any field changes, a save/cancel action bar appears at the bottom of the page. The bar is dismissed on save or cancel. This is less clunky than mode-switching.

State change and item update are separate API calls. The UI knows whether a state change is new or was already saved, so it can send a PATCH (update) vs a POST (state transition) as appropriate. The server handles the state transition logic; the client handles routing.

Toggle button UI for state selection was implemented and styled. HTTP PATCH was a new concept explored this week — along with ETags for concurrency, which was noted as interesting but not implemented.

Learnings

type="button" on button elements: if you don't specify the type, HTML defaults to type="submit", which submits the nearest form. Any button inside or near a form that should not submit it needs type="button" explicitly.

Next Week

Wire the state change buttons to actual behavior. Get a simple item update to work end to end.