Senior front-end interview course · Lesson 02

Before choosing a store, find the source of truth.

Estimated time: about 6 minutes

Many state bugs are not caused by the wrong library. They are caused by storing the same fact in two places.

The three questions

1

Is it authoritative?

Who owns the fact: the component, the URL, the browser, the server, or the user’s draft?

2

Is it derived?

Can it be calculated from existing state? If yes, avoid storing a second copy.

3

Is it cached?

Could it be stale, refetched, invalidated, or shared across screens? That suggests server state.

Redundant state

Suppose a form stores firstName, lastName, and fullName. The third value is derived:

const fullName = firstName + " " + lastName;

Storing fullName creates two values that must remain synchronized. React recommends avoiding redundant and contradictory state. Read the React guidance.

Server state versus client state

Server state

  • Owned by a backend
  • Asynchronous and remote
  • Can become stale
  • Needs caching and invalidation
  • Examples: users, orders, products

Client state

  • Owned by the current UI/session
  • Usually synchronous
  • Represents local decisions
  • Examples: open modal, draft filter, selected IDs

Interview rule: Don’t copy server data into Redux/Zustand merely because several screens need it. A server-state library can share the cached result while preserving the API as the authority.

A subtle example

A product page fetches a product. The user edits the quantity before adding it to the cart.

Good split: product details are server state; the draft quantity is client state; the cart mutation is a server interaction whose pending/error/success lifecycle may be handled by the server-state tool.

Retrieval challenge

Decide whether each value is authoritative, derived, cached server state, or temporary client state:

  1. isSidebarOpen
  2. visibleTodos, calculated from todos and a filter
  3. The response from /api/orders
  4. A search box’s current text before submitting
  5. isLoading manually duplicated in three components
  6. The selected page number encoded in the URL
  1. Temporary client state.
  2. Derived state; calculate it.
  3. Cached server state.
  4. Temporary client state, or URL state if the search is shareable.
  5. Likely a modeling smell; derive loading status from the request owner/cache.
  6. URL state and therefore browser/navigation-owned.

Interview prompt

“How would you prevent stale data when two screens edit the same record?”

A strong answer mentions a single server-state cache, query keys, invalidation or targeted updates after mutation, optimistic updates only when justified, and conflict/error handling. Avoid promising that a client store automatically solves server consistency.

Primary reading

Read TanStack Query’s overview, then revisit Choosing the State Structure.

Next lesson: Context, external stores, subscriptions, and performance trade-offs.