Model Client-State Transitions with Reducers

The Comparison Tray lets a user select local products—Notebook, Pen, Mug, and Lamp—then compare selected items, remove items, or clear the tray.

A reducer is a function that maps a current state and an action (a meaningful user intention) to a next state. It is useful when one user intention must consistently apply related rules across the feature.

Several state values alone do not require a reducer. A simple, independent value can remain easy to manage with local useState.

Choose a reducer when transitions are coordinated: one action can affect more than one part of the feature state, and the same rules must hold no matter where that action originates.

A state contract names the smallest data the Comparison Tray needs to remember. The tray remembers which product IDs are selected and whether the user explicitly opened comparison.

It does not store the selected count or a separate “can compare” flag. Calculate those values from selectedIds whenever the interface renders.

Two selected products make opening available, but they do not mean that comparison is already open. Opening is an explicit user choice, so isOpen must be stored.

Create src/features/comparison/comparisonReducer.ts. The fixed local catalog gives us a narrow ProductId union, so an unknown string cannot be selected by mistake.

ComparisonState has exactly two fields. initialState starts with no selections and a closed comparison. The capacity is a named rule rather than a repeated magic number.

src/features/comparison/comparisonReducer.ts

Before implementing transitions, write the invariants: conditions that every valid snapshot must satisfy.

1. Every selected ID is unique.
2. The selection contains no more than three products.
3. If isOpen is true, at least two products are selected.

The reverse of rule 3 is not required. A tray with two or three selections may still be closed, because permission to open is not the same as an open comparison.

A reducer action names an application intention. It does not describe a low-level field assignment.

For the Comparison Tray, “open the comparison” is meaningful even if the rule for opening later involves more than one state field. Model that intention as comparisonOpened, not as an instruction such as “set isOpen to true.”

This gives every transition a vocabulary that matches what the user is trying to do: add an item, remove an item, open, close, or clear.

In src/features/comparison/comparisonReducer.ts, define one union for every permitted Comparison Tray intention. ProductId is the catalog identifier type defined with the tray state contract.

Each union member has a literal type value. That shared field is the discriminant: TypeScript can use it to determine which fields belong to a particular action.

Only adding and removing identify a product. Opening, closing, and clearing already express complete intentions, so they carry no extra payload.

The discriminant prevents vague or malformed objects. Once an action is identified as itemAdded or itemRemoved, its productId is available as a ProductId. For an action identified as comparisonOpened, there is no product ID to read.

Likewise, an object such as { type: 'comparisonOpened', productId: 'notebook' } does not match this contract. Type checking catches that unnecessary payload when the object is written as an action.

comparisonReducer is the rule boundary for the Comparison Tray. It receives the current state and a semantic action, then returns the next state.

A branch returns a new state object only when the transition is allowed. For a blocked or irrelevant action, return the existing state. This keeps the rules true even if an action reaches the reducer without the expected interface control.

For this tray:

• Adding is blocked for an existing ID or a full selection.
• Removing an existing ID can also close an open comparison.
• Opening is blocked until two products are selected.
• Closing keeps the selection.
• Clearing restores the empty, closed state.

Place comparisonReducer below the state and action contracts in src/features/comparison/comparisonReducer.ts. The switch narrows action by its type.

The itemAdded branch rejects duplicate and full-tray requests. When it accepts an ID, array spread creates a new selection in insertion order. Object spread retains the current isOpen value, so adding an item does not silently open or close the comparison.

Addition branch inside comparisonReducer

Removal needs a coordinated result. First ignore an ID that is not selected. For a real removal, create the filtered array, then use its length to decide whether an open comparison must close.

The other branches preserve unrelated fields. Opening requires at least two selections, closing preserves the selection, and clearing restores the known empty, closed starting state.

Continue the same switch (action.type) block.

A reducer is a calculation: it receives the current state and one semantic action, then returns the next state. For the same inputs, it should always produce the same result.

Keep it self-contained. Do not mutate state or action, write to browser storage, change the DOM, start a request, read the clock, or use random values. Those operations depend on or change something outside the reducer.

The following branch is deliberately incorrect. The storage write is an external effect, so it must not run while React is evaluating a state transition.

Deliberately incorrect reducer branch—do not copy this pattern.

An event handler can own user-triggered external work. If that work is asynchronous, it may wait for completion and then dispatch an ordinary action with the relevant application data. The reducer itself still returns a ComparisonState immediately—not a promise.

Effects remain for synchronizing React with external systems. They are not a substitute for calculating the next Comparison Tray state.

A reducer branch computes and returns the state immediately.

ComparisonTray owns its local state. Inside the component, useReducer connects the existing comparisonReducer and initialState to two values:

• state is the current tray snapshot used for rendering.
• dispatch sends a semantic action to the reducer.

Importing a reducer module centralizes transition rules, but it does not create shared storage. Each mounted ComparisonTray has its own state.

Create src/features/comparison/comparisonReducer.ts, or confirm that your existing file contains this complete reducer implementation. It remains independent of React; the component will import its named exports.

Create src/features/comparison/ComparisonTray.tsx. This component derives display values during rendering and dispatches only application data from its controls.

Replace the contents of src/App.tsx with this local mounting example. Run your existing Vite app after all three files are in place.

A trace is a chain, not a set of independent reducer calls. Begin with initialState, pass it with the first action to comparisonReducer, and then pass that returned state into the next call.

A guarded action can return the exact current state. Record that unchanged snapshot and continue from it; do not restart from initialState. At every row, inspect both selectedIds and isOpen, then check the tray rules: IDs stay unique, no more than three are selected, and an open comparison has at least two selections.

Create src/features/comparison/traceComparison.ts with this temporary trace. Then, at the top of src/App.tsx, directly after the existing ComparisonTray import, add this side-effect import:

import './features/comparison/traceComparison';

Vite now evaluates the trace module when it loads App.tsx, so inspect the browser console while the app runs. These are ordinary typed calls, not a test framework. Remove the temporary side-effect import from src/App.tsx after checking the trace.

The interface reflects the same timeline. The count is derived from selectedIds, so two selected products render 2 of 3 selected. The inline Comparison section additionally requires isOpen.

After the successful open action, two selected products show the panel. A duplicate addition, an over-capacity addition, and removal of an absent product do not change what is visible. Removing pen leaves two selections, so the panel remains open. Removing mug next leaves only one selection, and that transition closes the panel.

A complete Comparison Tray interaction can cross several state fields, but the interface still reads one current snapshot. The action contract describes intent, the reducer applies the rules, and the rendered controls provide feedback from the resulting state.

Review this sequence as one continuous trace: select products, explicitly open comparison, remove a product, then reset the tray. The visible panel must agree with isOpen, while the count is derived from selectedIds.

Complete the removal branch so that a successful removal also preserves the open-comparison rule. This branch already handles an absent product by returning the existing state.