Which state belongs to the draft?
A draft contains the values the user is currently editing. A submitted request is a snapshot of the values used for an operation. A generated output is a result, which may arrive after the draft has changed. Treating all three as one object makes it hard to answer which settings produced a preview.
For example, imagine editing a prompt while an earlier request is still processing. The arriving result should not silently imply that it used the newly edited prompt. The interface needs enough context to keep that distinction visible.
Prefer explicit operation states
An operation may be idle, queued, processing, succeeded or failed. A set of independent flags can allow contradictory combinations, such as displaying both a loading indicator and a terminal error for the same request.
Use a state model that represents the product’s real transitions. Keep derived labels and presentation out of the stored state when they can be calculated. React’s state-structure guidance is a useful foundation for avoiding contradictory and redundant state.
What should happen to a late response?
A response can arrive after the user has selected another item or started another operation. Decide whether it belongs in the active preview, in that item’s history or only in a background status indicator. That is a product rule before it is an implementation detail.
Associate the result with the operation and target object that produced it. Do not let whichever response finishes last automatically become the current selection. A useful test deliberately completes two requests out of order.
Keep rendering separate from coordination
A visual component should receive the state and actions it needs to render its control. Request coordination, permissions and retry rules belong in the surrounding feature logic or a focused hook. This keeps a button, card or panel understandable without requiring it to know the whole workflow.
The boundary should remain small. Extracting a generic abstraction for a single mapping can make code harder to follow. Start with the simplest boundary that isolates the actual responsibility.
Test transitions that can confuse a user
Prioritise behaviours with observable consequences: a retry after failure, navigation while processing, a late response and a changed selection. The assertion should describe the visible contract, such as which preview stays selected.
A useful implementation makes state readable to both people maintaining the code and people operating the product. More indicators do not help if they describe incompatible versions of the same task.
- Draft edits do not rewrite the submitted input.
- Late results stay associated with their original target.
- Failure exposes a scoped recovery action.
- Visual components receive clear state and callbacks.