Question 1

What is state management, and why is it hard?

Accepted Answer

**State** is any data that changes over time and affects behaviour. Managing it is hard because state creates **dependencies across time** — and time is the dimension our reasoning handles worst.

**Why it is genuinely difficult:**

**Behaviour depends on history.** A pure function with the same inputs always gives the same output, and can be understood in isolation. A stateful component's behaviour depends on everything that happened before, so understanding it means understanding a sequence rather than a snapshot.

**Combinatorial explosion.** Ten independent booleans are 1,024 possible states. Most cannot be reasoned about individually, and bugs live in the combinations nobody enumerated.

**Synchronisation.** Once the same fact is stored in two places — component and server, cache and database, two tabs — they can disagree, and reconciling them is genuinely hard rather than merely fiddly.

**Shared mutable state across concurrent execution** is the classic source of race conditions.

**Invalidation.** Knowing when derived or cached state is stale is famously one of the hard problems.

**The distinctions that actually help:**

**Server state versus client state.** These are frequently conflated and behave completely differently. Server state is a **cache of something you do not own** — it can be stale, needs refetching, and needs loading and error handling. Client state is genuinely yours: form input, which modal is open, theme. Libraries dedicated to server state exist precisely because treating it as ordinary local state produces endless bugs.

**Derived versus stored.** If a value can be computed from other state, compute it. Storing it creates a second source of truth that can drift — the most common self-inflicted state bug there is.

**Local versus shared.** Keep state as close to where it is used as possible. Lifting everything into a global store is a common over-correction that makes changes harder to reason about, not easier.

**Ephemeral versus persisted**, and how it survives reload.

**Unidirectional data flow** and **immutable updates** help mainly by making changes traceable.

Question 2

Why is cache invalidation considered hard?

Accepted Answer

The famous quip from Phil Karlton is that there are two hard things in computer science: cache invalidation and naming things. The joke endures because the problem is genuinely difficult, and the

Question 3

Why is my React state not updating immediately?

Accepted Answer

State updates are not applied immediately. Calling the setter schedules a re-render; it does not change the variable you are currently holding. Reading that variable on the next line gives you the

Question 4

What is eventual consistency?

Accepted Answer

Eventual consistency is a guarantee that, if no new updates are made, all replicas of a piece of data will eventually converge on the same value. It does not guarantee when, and it permits reads that

Question 5

What does "immutable" mean and why does it help?

Accepted Answer

An immutable value cannot be changed after it is created. Operations that appear to modify it return a new value instead, leaving the original intact. Why this helps, and the reasons compound: You

Question 6

What is a race condition in a React useEffect and how do I avoid it?

Accepted Answer

The problem appears whenever an effect starts an asynchronous request that depends on a changing value. If the value changes again before the first request finishes, two requests are in flight, and

Question 7

When should I use useMemo and useCallback?

Accepted Answer

Both cache something between renders. Memoising a value caches a computed result; memoising a callback caches a function identity. They are the same mechanism applied to different things, and both

Related Questions