How would you standardise submission handling across dozens of forms in one application, and what must stay per-form?

## Why standardise this at all Submission is where a product's forms are most visibly inconsistent and most expensively wrong. Left to each screen, you get a different pending feel per form, a different wording for "the network failed" versus "the server said no", some forms that lose input on rejection, some that duplicate writes, and rejected saves that are silent because that form's author did not handle an unmapped complaint. None of those are hard problems; they are problems that recur once per form. ## What the shared primitive should own - **One unit-of-work state.** A submission is `idle`, `pending`, `succeeded` or `failed`, and carries its result and its error. One value, not three booleans that can express nonsense like pending-and-failed. - **The guard.** A synchronous in-flight marker (or the in-flight request itself) so a second start returns the first rather than duplicating it. - **The request key.** Generated once per attempt, reused by retries of that attempt, retired on settlement. - **Failure classification.** Transport failure, rejection with field complaints, rejection without them, conflict, authorisation loss, and the different treatment each deserves. - **Server-error mapping.** Rejections become messages keyed by payload path, with everything unmatched surfacing at form level rather than disappearing. - **Announcement and focus.** A live region for start and settlement; focus to the first offending field in document order, or to the summary. - **Latency behaviour.** The delay before a spinner appears, the threshold at which the interface says the work is slow, and what it offers then. ## What must stay with each form 1. **The payload mapping.** How this form's fields become the request body, including coercion and the values no control carries. This is the part that is genuinely different every time. 2. **The rules.** Which client-side rules exist and when they run. 3. **The copy.** Field labels and messages that are specific to this domain. 4. **The post-success policy**, because it follows the task and not the mechanism: - a create-another flow resets the fields; - an edit form keeps the values and re-baselines what counts as dirty, since the values are now the saved truth; - a one-shot flow replaces the form with a result; - a step in a longer flow hands off and lets the next step own the screen. | Concern | Shared | Per-form | |---|---|---| | Pending, result, error as one state | yes | no | | In-flight guard and request key | yes | no | | Rejection to field-path mapping | yes | the path vocabulary for its own payload | | Focus and announcement on failure | yes | the wording | | Payload assembly and coercion | no | yes | | What success does to the screen | the settlement point | the policy | ## Adopting what the framework already offers Where the framework tracks a submission started through a form as one unit — its pending status, its returned result, its error — adopt it rather than re-implementing it: it settles even when the handler throws, and any control can read the status without being handed it. Wrap it in a thin adapter so the forms depend on your submission contract instead of the framework's surface. That adapter is cheap insurance: it is also where you add the parts the framework does not cover, notably the request key and the remount-proof guard. ## The failure mode of over-standardising A shared submission primitive that also owns validation, payload shape, layout and copy becomes an in-house framework no one can opt out of, and the first screen that does not fit gets a flag added for it. Two disciplines keep it honest: - **Escape hatch first.** A form must be able to use the guard and the state without accepting the rest, and one that cannot fit should be able to drop out entirely without deleting the shared piece. - **Additive by policy, never by flag.** New behaviour is a new option with a sane default, and if you are adding the third boolean to accommodate one screen, that screen wants its own path. ## How you know it is working This is measurable, and treating it as a matter of taste is how it regresses: - **Duplicate-write rate** per endpoint — the only real test of the guard and the request key. - **Unmapped-error rate** — rejections that produced no field message, which tells you the payload and the forms have drifted. - **Stuck-pending reports** — forms that never settled, which point at a handler throwing outside the settle path. - **Time-to-settle distribution**, because the latency thresholds you chose are only right for the latency you actually have. The short version to say out loud: share the mechanism and the failure handling, keep the meaning and the copy local, adopt the framework's tracked submission behind an adapter, and put a number on duplicates and on silent rejections so the shared piece has to keep earning its place.