How do you structure one form model across several steps so each step validates its own subset and going back keeps state?

## One model, several views The first decision is whether each step owns its own state or whether all steps are views over a single model. Almost everything downstream follows from it. | Concern | Model per step | One model, step slices | |---|---|---| | Cross-step rules | need copies or a shared side channel | natural: both paths are in scope | | Going back | restore or re-seed; drift likely | re-render from the model | | Review screen | gather from several sources | read the model | | Payload | merge, with a chance of disagreement | project the model once | | Step isolation | strong, and usually not what you need | weak by design | One model wins for anything beyond two trivial steps. The cost is that "valid" is no longer a single question: the form is *partially* valid, per step, and the design has to say what that means. ## Declare step membership as data Give each step a **declared set of paths** — literal paths, path prefixes, or a predicate — rather than encoding it inside the step's markup. One declaration then serves several readers: - the advance gate, which validates only that subset; - the review or summary screen, which lists a step's fields in order; - a path-to-step lookup, so anything the form learns about a path can send the user to the step that owns it; - progress reporting, which needs to know how much of each step is filled. Prefixes matter because a step often owns a whole repeating group: declaring the group's root covers every row that exists now or later, while a hand-written list of row paths is wrong the moment a row is added. ## What "valid enough to advance" means Advancing runs the rules whose paths fall in the current step's set, and nothing else. Two failures are common: 1. **Validating the whole model to advance.** Required fields two steps ahead report errors immediately, and the user sees a form that objects to fields it has never shown. This is the single most recognisable multi-step bug. 2. **Never validating the whole model.** Each step passed in isolation, so a cross-step rule — a date range spanning two steps, a total that must match a sum entered earlier — is only discovered at submit, or not at all. So there are two gates, and they are different: a **per-step subset gate** to advance, and a **whole-shape gate** before submitting. Cross-step rules belong to the whole-shape gate, and may also run on the later of the two steps once both paths have values. ## Going back, and what must survive Going back is a view change. What must survive is the whole model, plus the interaction flags — a field the user already fixed should not present as untouched, and a step already completed should not lose its verdicts. What must *not* happen: - re-seeding the step from defaults, which silently discards the user's typing; - clearing later steps because "they may now be stale" — unless a genuine dependency says so, in which case clear exactly those paths, not everything; - resetting the step's verdicts so a previously failing field looks clean. If the flow may be resumed after a reload, the surviving unit is the same one: the model plus enough flags to redraw the current position. Deciding what is persisted, and where, is a structural choice made once for the whole flow rather than per step. ## Conditional steps Branches make the **step list itself** dynamic: a choice on step one can remove step three entirely. That means the list of steps is derived from the model, not a constant, and the fields of a skipped step are governed by the same conditional policy as any hidden field — dropped, parked, or deliberately submitted, with their rules made inapplicable rather than merely unsatisfied. The whole-shape gate therefore validates the **active** shape, which is exactly the projection the payload is built from. ## The tradeoffs a lead is choosing - **Granularity of the declaration**: literal paths are precise and rot; prefixes and predicates survive refactors but can over-capture. - **Where the model lives**: inside the flow's component subtree means it dies if the user navigates away; outside means it outlives the flow and needs explicit disposal. - **How much state is persisted**: resumability is a product promise with a storage and privacy cost, and half-filled sensitive fields are the reason to decide it deliberately. - **Strictness of advancing**: blocking on a subset is predictable; letting users skip forward and marking steps incomplete is friendlier and needs a per-step completeness notion. ## Interview shape Say "one model, steps as declared slices of paths", give the two gates, then the back-navigation invariants, then name the tradeoffs you would put to the team. The answer interviewers reward is the one that treats a wizard as a projection problem over a single state model rather than as a sequence of forms.