Topic

Choosing the state structure

Definition

Well-structured state stores minimal, non-redundant values in a shape that reflects independent changes.

In simpler words

Keep only the values you cannot calculate from other values, and avoid contradictory copies.

Avoiding redundancy, duplication, and deeply nested state.

Open official example (opens in new tab)

After this you can

Choose state that remains easy to update and reason about.
Explain the trade-off to a teammate using a small example.
Name at least one common bug pattern for this topic.

Understand Choosing the state structure

Avoiding redundancy, duplication, and deeply nested state.

Start by identifying which value or browser behavior changes. Then describe the UI from that current input instead of editing the DOM as a separate source of truth.

Choosing the state structure in code

const visibleTickets = tickets.filter(ticket =>
  filter === "all" || ticket.status === filter
);

Read the example from data and control flow to the resulting UI. Keep the component boundary small.

Apply Choosing the state structure

Keep rendering as a calculation. Put user-triggered changes in event handlers, preserve UI memory in state, and reserve external synchronization for Effects or the server-state layer.

Name values by their UI meaning, test the loading and error path when data is remote, and avoid keeping two editable copies of the same value.

Ask before adding code: is this local UI memory, shared client state, or Nest-owned server state?

Where bugs hide

Definition

High-bug areas are places where a small API misuse looks correct but produces stale UI, duplicate work, or silent failures.

In simpler words

Each mistake below shows Wrong vs Right code — compare them side by side.

When something misbehaves, match the symptom to a pattern below before rewriting the feature.

Prefer fixing the ownership or update path over adding another Effect or sync step.

Mistake: Storing derived filtered list

// Wrong
const [visible, setVisible] = useState([]);
useEffect(() => setVisible(items.filter(...)), [items, filter]);

// Right
const visible = items.filter(...);

Derive during render — no sync Effect.

Mistake: Two copies of the same field

// Wrong
const [title, setTitle] = useState("");
const [ticket, setTicket] = useState({ title: "" });

// Right
const [ticket, setTicket] = useState({ title: "" });
// read ticket.title

One source of truth prevents disagreement.

Mistake: Deep nesting for forms

// Wrong
state.user.profile.settings.theme

// Right
// flatter: theme + profileId, or multiple small states

Deep trees make immutable updates error-prone.

Live playground

Choosing the state structure sandbox

Change one input at a time and predict the next render.

Prefer deriving openCount — mirrored state can drift.

Derived open count: 2

Mirrored open count (extra state)

Keep in mind

Keep the formal definition in mind; it explains which tool belongs where.
Prefer one source of truth over synchronized copies of the same value.
When behavior surprises you, trace: input → update → render → committed UI.
Study the Wrong vs Right examples in “Where bugs hide” before you merge.

Test

Check your understanding

At least 10 questions — mix of concept, syntax, practical, and logic. Score ≥80% (enforced by the API) to save progress.

Checking your session…

15 questions · concept 5 · syntax 3 · practical 4 · logic 3

1. What is the guiding rule?

Concept

Mirror every derived value into its own useStatePrefer minimal state and derive values during render when possibleStore the entire Nest database shape in one componentDuplicate filters in state and URL without a single owner

2. Selected id instead of selected object copy?

Syntax

Store id; derive the object from the listStore a deep clone of the selected object in stateStore both the id and a copy of the object, synced by an EffectStore the array index of the selected item instead of its id

3. Redundant state smell?

Practical

Storing an in-progress form draft the user is editingStoring whether a modal is currently openfirstName + fullName both stored while fullName is just concatenationStoring the id of the currently selected tab

4. Why avoid deeply nested state?

Logic

React only tracks changes to the top level of a state objectNested objects cannot be passed as props to child componentsDeeply nested state is always slower to read during renderUpdates become painful copy trees; flatten when sensible

5. Syncing two states that must match?

Concept

Add a useEffect that copies one into the other whenever either changesUsually collapse to one state or derive oneKeep both and reconcile them right before every renderStore one in state and the other in a ref, syncing on each keystroke

6. List + selectedIndex risk?

Practical

The index resets to 0 on every re-renderReact forbids using numbers as state valuesStoring the index causes the list to re-sort itselfIndex can point wrong after sort/filter — prefer selectedId

7. Server entity vs client draft?

Syntax

Copy the server entity into the draft slice with an Effect on loadKeep server cache (Query) separate from local draft state (RTK/useState)Store both the server cache and the draft in a single Redux sliceRender draft rows inside the Query-backed list for one source

8. Is mirroring props into state OK?

Logic

Always mirror props into state so children can re-renderOnly when you intentionally need a draft; else use props directlyMirror props into state and resync them with an Effect on changeNever read props directly; copy them into refs first

9. Derived total price?

Concept

Store total in state and update it in an Effect on cart changesCompute from cart items during renderKeep total in a ref and recompute it inside an event handlerStore a per-line total and sum the stored subtotals

10. Which structure is worst?

Practical

Storing the full list and deriving the filtered list during renderStoring the current filter string in stateStoring filteredList and fullList and manually syncing bothStoring the selectedId and deriving the selected item

11. Which piece of state is redundant here?

Conceptintermediate

const [first, setFirst] = useState('Ada');
const [last, setLast] = useState('Lovelace');
const [fullName, setFullName] = useState('Ada Lovelace');

first — it duplicates fullNamelast — names need only one fieldNone; all three are requiredfullName — derive it from first and last during render

12. Why is selectedIndex fragile in this component?

Syntaxadvanced

const [items, setItems] = useState(list);
const [selectedIndex, setSelectedIndex] = useState(0);
// user sorts items...
const selected = items[selectedIndex];

Indexes cannot be stored in stateAfter sorting, the index points at a different item; store selectedId insteaditems must be a refReact forbids indexing arrays

13. What is the simpler correct approach here?

Practicalintermediate

const [cart, setCart] = useState(items);
const [total, setTotal] = useState(0);
useEffect(() => setTotal(sum(cart)), [cart]);

Keep the Effect; it is requiredCompute const total = sum(cart) during render — no state or EffectMove total into NestStore total in a ref

14. Why is this state shape a smell?

Logicadvanced

const [all, setAll] = useState(rows);
const [filtered, setFiltered] = useState(rows);

filtered should be a refTwo lists must be kept in sync; keep all + a filter string and derive filteredall should live in NestBoth must be memoized

15. What limitation does this initializer have?

Conceptintermediate

function Editor({ ticket }) {
  const [title, setTitle] = useState(ticket.title);
  // ticket prop can change later
}

It re-syncs on every prop change automaticallyuseState cannot accept propsIt only seeds once; later ticket prop changes won’t update title unless you remount via keyIt causes an infinite loop

Checking your session…