Model async form states

The save button disables during one request, errors are announced, and the form returns to a usable state after failure. This is a small part of an accessible issue board that filters, edits, persists, and progressively enhances server-rendered HTML, but the boundary it creates affects everything that follows.

An enhanced form needs an explicit lifecycle and a final cleanup path even when fetch throws or the server rejects input. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

Watch for one shortcut in particular: trying to set a loading boolean before fetch and forget to clear it on exceptions. It makes later failures harder to locate. Instead, use a try/catch/finally flow, keep server errors visible, and make repeated submission behavior intentional. Prefer an implementation you can explain from the outside before optimizing it.

Keep the wider goal in view: Build a keyboard-usable issue editor whose state, validation, and submission lifecycle remain explicit. A short observation with concrete evidence is more useful than a confident sentence with no reproduction path.

Simulate slow success, validation failure, network failure, and double click; verify controls and messages each time. Hand the result to someone else and see whether the behavior is clear without an oral explanation.