Designing a multi-step wizard form pattern
orchestrating multi-step flow plus per-step state.
a wizard controller owns step index and shared data, each step validates itself and reports up, accumulated data persists across steps.
What's really being asked
The interviewer is assessing orchestration design: managing flow and shared state centrally while letting each step stay an encapsulated, independently validated component, and ensuring data survives navigation.
The full answer
Introduce a wizard controller that owns the cross-cutting state: the current step index, the navigation actions next, back, and finish, and an accumulated data object holding values from all steps, exposed through context or a hook. Each step is a distinct component responsible for its own fields and validation; it reads any previously entered values for its section from the shared store so revisiting shows prior input, and on a next attempt it runs its own validation and, only if valid, merges its values into the accumulated store and advances. This keeps steps decoupled (the wizard does not know each step's fields) while persistence is centralized so moving back and forward never loses data. The controller gates navigation on the current step's validity, computes whether next or finish should show, and on finish submits the combined data. Persisting the accumulated store to session storage guards against refresh.
The mistakes people make
Storing each step's values only in that step's local state, so going back unmounts it and loses the data. Centralizing all validation in the wizard, coupling it to every step. Letting steps navigate themselves without the controller gating on validity. Submitting per step instead of collecting and submitting once.
What usually comes next
How do you handle conditional or branching steps? How do you validate cross-step dependencies? How do you allow jumping to a visited step?
A concrete example
A checkout wizard controller holds step index and an accumulated order object. The Shipping step validates its address and on next merges it into the store; the Payment step reads nothing from shipping but adds card details; pressing back returns to Shipping with the address still filled. Finish submits the combined object once, and the store is mirrored to session storage so a refresh resumes mid-flow.
Interview question
In a wizard form, why should step values be merged into a shared accumulated store rather than kept only in each step's local state?
- a.So navigating back and forth preserves previously entered data across stepsCorrect
- b.So validation logic can all live inside the controller
- c.So the wizard controller can render every step simultaneously
- d.So each step can validate the other steps' fields
Why? this is the answer
Centralizing accumulated values lets data persist when a step unmounts on navigation, so going back shows prior input. Steps still own their own validation, and the store is about persistence, not rendering all steps at once.
Just read this? Test yourself on what you have been reading.
Read the original → patternfly.org
- #wizard
- #multi-step-form
- #state-management
- #flow-control
- #component-design
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles