Repair a Drifting Order Summary
This feature has already been implemented, but a customer reported that changing seat quantities leaves the monthly subtotal at $48.00.
Your job is to reproduce the defect, find its root cause, and make the smallest durable repair in an existing subscription settings screen. The UI already handles seat boundaries; the summary is the part that regressed.
Requirements
- Keep the existing seat controls and their minimum value of one.
- Make the subtotal reflect the latest
items on every render.
- Treat
items as the single source of truth.
- Do not add an effect to synchronize one state value with another.
- Do not mutate the items array or its objects.
- The subtotal must update after changing either product, including repeated changes in one interaction.
What to explain during an interview
- Why did the subtotal drift away from the displayed seat counts?
- Why is calculating the subtotal during render preferable to synchronizing another state variable?
- When would storing a calculated value in state be justified?
Progressive hints
- Identify which displayed values can change and which state controls each one.
- Ask whether
subtotal represents independent user input or a calculation from existing state.
reduce can calculate the total of price * seats for the current items.
Reference solution notes
The reference removes the second source of truth and computes the subtotal from items during render. This is preferable to an effect because the value is a pure projection of current state: there is no synchronization window, extra render, or dependency list to maintain. A valid alternative is a memoized calculation when the item collection is genuinely large, but memoization does not repair duplicated state. Common mistakes include updating the hard-coded initial value, using an effect to copy items into subtotal, mutating an item in place, or allowing a decrement below one.