Kinds of state

The problem: one box for everything

Picture a project-management board, the kind every team uses. We will call it Boardly. It has columns like To do, In progress, and Done, and each column holds cards.

You can filter by person, search by title, open a card in a side panel, and edit its description. You can also see the faces of teammates who are looking at the same board right now.

The first version of Boardly was built fast. The team made one global store and put everything in it: the cards, the columns, the open card id, the search text, the description being typed, the list of people online, and whether the sidebar is collapsed. One box, one place to look. It felt simple.

Six months later the bug tracker looks like this. Each bug below is typical of real apps, and every one comes from the same root cause.

• Stale cards. Priya moves a card to Done. Her teammate Sam still sees it in In progress until he reloads, because his copy of the cards was fetched once at login and never refreshed.
• Lost filters. Sam filters the board to "my cards, label: bug" and sends the link to his lead. The lead opens the link and sees the whole unfiltered board, because the filter lived only in the store.
• Broken back button. Opening a card and pressing Back leaves the app instead of closing the card.
• Wiped drafts. Sam is halfway through a long card description when a background refetch arrives and replaces his text with the saved version.
• Slow typing and dragging. Teammates' cursor positions arrive about 20 times a second. Each update goes into the global store, and many components that read the store render again. Typing in the search box starts to lag.

Five bugs, one cause

None of these is a bug in a library. Each one comes from treating very different values as if they were the same kind of thing.

The cards are a copy of data that lives on a server, so they go stale. The filter is something the user wants to share and bookmark, so it belongs in the URL. The description is a draft that the user owns until they press Save. The cursors are a stream that changes many times a second and is useless a moment later.

Each of those kinds has different needs: how long it lives, who owns the truth, who else needs to see it, and how often it changes. Put them in one box and you get one set of rules for all of them, which is the wrong set for most of them.

This is why system design interviewers listen for the split early. When a candidate says "I'll put everything in Redux", the interviewer hears the five bugs above. When a candidate sorts the state into kinds and gives each one a home, the rest of the design (caching, routing, real-time, forms) follows from that choice.

What counts as state

State is any value that can change while the page is open and that changes what the user sees. The title of a card is state. So is whether a menu is open, which card is selected, the text half-typed into a box, and the green dot that says a teammate is online.

Two kinds of values are not state, and spotting them early saves a lot of code. Constants never change while the page is open, such as the list of column colors. Derived values can be computed from other state, such as "12 cards match your filter": store the cards and the filter, and compute the count when you render. Storing a derived value next to its sources means two copies that can disagree.

The mental model: five kinds, five homes

Almost every value in a frontend app falls into one of five kinds. Each kind has a natural home: the place that owns the truth and the tool built for it. Learn these five and you can sort any app's state in a few minutes.

1. Server state. Data that lives in a database and that you only hold a copy of: Boardly's cards, columns, members, and comments. Home: a server-state cache (a library such as TanStack Query, SWR, RTK Query, or Apollo, or the cache in your framework).
2. Client UI state. Values that only this tab cares about and that nobody would share: is the sidebar collapsed, which menu is open, which card is being dragged. Home: the component that uses it, or a small store if many distant components need it.
3. URL state. Values that describe what the user is looking at and that should survive a reload, a shared link, and the Back button: the board id, the filters, the search text, the open card. Home: the path and the query string.
4. Form state. A draft the user is writing that is not saved yet, plus its bookkeeping: the values, which fields were touched, which are invalid, and whether a save is in flight. Home: the form itself, often with a form library.
5. Stream state. Values pushed by the server many times a second that are only true right now: who is online, where their cursors are, a "Priya is typing" hint. Home: a small buffer outside the render tree, read at a steady rate.

Four questions that sort any value

You do not need to memorize lists of examples. First rule out derived values and constants, as in the first chapter. Then four questions decide the kind of almost any value: ask them in order and stop at the first yes.

1. Who owns the truth? If the answer is a server (the value is in a database, and other users can change it), it is server state, or stream state if it changes many times a second and is never stored.
2. Should it survive a reload or a shared link? If a teammate who opens your link should see the same thing, it is URL state.
3. Is it something the user is writing and has not saved yet? Then it is form state, owned by the user until they submit.
4. Otherwise it is client UI state: local to this tab, cheap to lose, and usually local to one component.

Two more properties help with edge cases. Lifetime: does the value matter for a frame, a minute, a session, or forever? Rate: does it change once a minute or 60 times a second? A value that changes 60 times a second needs special handling whichever kind it is.

The five kinds side by side

An everyday comparison

Think of a shared office. The company records in the filing room are server state: you can take a photocopy to your desk, but the copy ages, and you go back to the filing room when it matters. The room number on your meeting invite is URL state: anyone with the invite finds the same room.

The letter you are drafting is form state: it is yours until you send it, and nobody should replace it with an old copy. Your desk layout is client UI state: nobody else cares. The voices in the open-plan area are stream state: useful right now, pointless to file away.

Server state: a cache, not a variable

The single most useful idea in this lesson: the client never owns server data. It holds a cache of it. The cards Sam sees are a photo of the database taken when the request returned. From that moment the photo starts to age, because Priya, a bot, or another tab can change the real thing.

Once you think of it as a cache, the questions you need to answer become clear. They are the same questions you ask of any cache: how is it keyed, when is a copy too old, when do we fetch again, and what do we do when we change the data ourselves.

The jobs a server-state cache does

• Key each piece of data. A request is stored under a key such as ["cards", { boardId: "b42", assignee: "sam" }]. Two components that ask for the same key share one entry and one request.
• Remove duplicate requests. If the column header asks for the board while the card list's request for the same key is still in flight, no second request goes out. See the request deduplication lesson.
• Track freshness. Each entry records when it was fetched. A setting called stale time (TanStack Query's staleTime, which defaults to 0) says how long the copy counts as fresh. Once it is stale, the next refetch trigger (a component mounting, the window regaining focus) shows the old copy at once and fetches a new one in the background. This pattern is called stale-while-revalidate.
• Refetch at the right moments. When the window regains focus, when the network comes back, when a mutation (a request that changes data) touches the data, or on an interval.
• Handle loading and errors. Every entry has a status: pending, success, or error, plus whether a background fetch is running. The UI reads that status instead of keeping its own isLoading flags.
• Garbage collect. Entries that no mounted component uses are dropped after a while (TanStack Query's gcTime defaults to 5 minutes), so memory does not grow forever.
• Apply your own changes. After a mutation, either invalidate the affected keys so they refetch, or update the cache directly, possibly before the server answers. That second option is the optimistic updates lesson.

The classic mistake: copying it into a client store

The Boardly team did this: fetch the cards in a useEffect, then dispatch(setCards(data)) into a global store. Now there are two copies of the cards: the server's truth and the store's photo. Nothing ties them together. Nobody wrote code to refetch on focus, nobody handles two requests for the same board arriving out of order, and every mutation must remember to patch the store by hand.

Each of those jobs is solvable, but solving them all is exactly writing a server-state cache. Libraries that do this are covered in the server-state libraries lesson in the data fetching module. In a design interview it is enough to say "server data lives in a query cache keyed by board and filter, with a 30 second stale time, refetch on focus, and invalidation after mutations".

function useBoardCards(boardId: string, filters: Filters) {
  return useQuery({
    queryKey: ["cards", boardId, filters],
    queryFn: ({ signal }) => api.listCards(boardId, filters, { signal }),
    staleTime: 30_000, // fresh for 30 s, then refetch in the background
  });
}

function useMoveCard() {
  const qc = useQueryClient();
  return useMutation({
    mutationFn: api.moveCard,
    onSettled: (_data, _err, vars) =>
      qc.invalidateQueries({ queryKey: ["cards", vars.boardId] }),
  });
}

Notice two details. The query key includes the filters, so "Sam's bug cards" and "all cards" are separate entries and switching between them is instant once both are loaded. And the request receives an abort signal, so a filter change cancels the old request. The request races lesson explains why that matters.

How fresh is fresh enough?

Stale time is a product decision, not a technical one. Ask: how bad is it if the user sees a value that is N seconds old?

For data that changes often and matters, polling or a push channel keeps the cache close to the truth. Pushed updates are stream state on the wire, but they usually end by writing into the server-state cache. We come back to that in the stream state chapter.

Client UI state: keep it close and small

Client UI state is everything the user does to the interface that nobody else needs to know about. In Boardly: the sidebar is collapsed, the "More" menu on a card is open, the user is hovering a column, a card is mid-drag, a toast is showing, keyboard focus is on the third card.

It is the easiest kind to handle and the easiest to over-engineer. Most of it is short-lived and used by one component, so the right home is that component's own state: useState in React, a ref in Vue, a signal in Solid or Angular.

Rule one: put it as low as it can go

Keep each piece of UI state in the lowest component that contains every reader of it. This is called colocation. If only the card menu reads isMenuOpen, the state lives in the card menu. If the column header and the card list both need collapsed, it lives in the column, their nearest shared parent.

Colocation has two payoffs. A change re-renders only the small subtree that cares, which keeps typing and dragging fast. And deleting a feature deletes its state with it, so there are no orphaned flags in a global store that nobody dares to remove.

When UI state really is global

Some UI state is read by distant parts of the page: the theme, whether the command palette is open, the toast queue, the current drag (so drop targets across columns can highlight). A context or a small store is fine for these. Keep that store small and only for UI state, never a second copy of server data.

Where the line sits between local and global, and how context, Zustand, Redux, and signals compare, is the topic of the local vs global state lesson later in this module. For this lesson the rule is: start local, lift only when a second distant reader appears.

Preferences: UI state that is remembered

Some UI state should survive a reload but is still personal: the theme, the collapsed sidebar, the board density. These are preferences. They are client UI state with a persistence layer, usually localStorage. If the user expects them on every device, they become server state (a user settings record) with a local copy for instant first paint.

• Read the stored value before the first paint, or the page flashes the default theme and then switches. For a server-rendered page that means a small inline script or a cookie the server can read.
• Wrap reads in a try block. Storage can throw in some private browsing modes and when the quota is full.
• Version the stored value ({ v: 2, density: "compact" }) so a later release can ignore or migrate old shapes.
• If two tabs can change it, listen for the storage event so the other tab updates. The cross-tab sync lesson covers this.

URL state: what the user is looking at

The URL is the oldest state store on the web, and the only one the browser already knows how to save, share, bookmark, and undo. URL state is anything that answers "what am I looking at?": which board, which filters, which sort, which page of results, which tab, which card is open.

The test is simple. If Sam copies the link and Priya opens it, should she see the same view? If Sam presses Back, should this change be undone? If yes to either, the value belongs in the URL.

Path or query string?

• The path names the resource: /w/acme/boards/b42. It should change rarely and be stable enough to bookmark for months.
• The query string holds the view settings on top of it: ?assignee=sam&label=bug&q=login&sort=due. Each one is optional and has a default, so a bare path still works.
• A nested path or a query key can hold an overlay such as an open card: /boards/b42/cards/c17 or ?card=c17. Both work; the path form reads better and lets the server render the card for a shared link.
• The hash (#comment-9) scrolls to a part of the page. The browser does not send it to the server, so the server cannot render based on it.

The URL is the source, not a mirror

The most common URL bug is keeping the filters in a store and in the URL, then writing code to sync them both ways. Two-way sync loops: the store updates the URL, the URL change updates the store, and a stray effect fires twice. Pressing Back changes the URL but not the store, and the board shows the wrong filter.

Make the URL the only copy. Components read the filters from the router (useSearchParams or your framework's equivalent) and write by navigating. Nothing else stores them. The URL then feeds the server-state key directly: change ?label=bug and the query key changes, so the cache fetches or reuses the matching data.

function BoardPage({ boardId }: { boardId: string }) {
  const [params, setParams] = useSearchParams();
  const filters = {
    assignee: params.get("assignee") ?? "anyone",
    label: params.get("label") ?? "all",
    sort: params.get("sort") ?? "manual",
  };
  const cards = useBoardCards(boardId, filters); // server state, keyed by URL state

  function setLabel(label: string) {
    const next = new URLSearchParams(params);
    if (label === "all") next.delete("label");
    else next.set("label", label);
    setParams(next); // pushes a history entry, so Back undoes it
  }
  // ...
}

Push or replace?

Every URL change either pushes a new history entry (Back undoes it) or replaces the current one (Back skips it). Pick per value. Opening a card or changing the filter is a step the user may want to undo: push.

Typing in the search box would add one entry per keystroke: replace while typing, or update the URL once the user pauses. Scroll position is not URL state. The browser and many routers restore it on Back, and long infinite lists may need to save it in history.state (see the pagination lesson).

Form state: a draft the user owns

When Sam opens a card and starts editing its description, a new kind of state appears. The text in the box is not the card's description yet. It is a draft: the user's own work, which may become server state when they press Save, or vanish when they press Cancel.

Form state is that draft plus the bookkeeping around it. Treating it as its own kind is what fixes the "wiped drafts" bug from the first chapter.

What form state holds

• Initial values: a snapshot of the server data at the moment editing began. They are used to reset the form and to tell what changed.
• Current values: what is in the fields now.
• Dirty: whether a field differs from its initial value. It drives the "unsaved changes" warning and enables the Save button.
• Touched: whether the user has visited and left a field. Show errors only after a field is touched, or a user sees a red "required" before typing a single letter.
• Errors: the result of validation, per field and for the whole form.
• Submit status: idle, submitting, succeeded, or failed with a server error to show.

Copy once, then let go of the server

The key rule: when editing starts, copy the server value into the form once, and stop listening to it. From then on the user owns the draft. The bug in Boardly came from binding the text box directly to the server-state cache. A background refetch (focus, interval, or a live update) replaced the cached description, and the text box followed it, wiping Sam's work.

Copying once means a teammate can change the same card while Sam edits. That is a real conflict, and hiding it is worse than showing it. A good design notices that the server version moved since editing began (compare a version number or updatedAt), and tells Sam "Priya changed this card while you were editing" with a choice, instead of silently dropping one person's work.

function DescriptionEditor({ card }: { card: Card }) {
  // key={card.id} on this component resets the draft when a different card opens
  const [initial] = useState(card); // snapshot taken once
  const [draft, setDraft] = useState(initial.description);
  const save = useSaveDescription();
  const dirty = draft !== initial.description;

  return (
    <form onSubmit={(e) => {
      e.preventDefault();
      save.mutate({ id: card.id, description: draft, baseVersion: initial.version });
    }}>
      <textarea value={draft} onChange={(e) => setDraft(e.target.value)} />
      {card.version !== initial.version && <p>This card changed while you were editing.</p>}
      <button disabled={!dirty || save.isPending}>Save</button>
    </form>
  );
}

After submit, the draft becomes server state

When the save succeeds, the value moves kinds. Update or invalidate the server-state cache so every view shows the new description, then clear or close the draft. If you want the board to update before the server answers, that is an optimistic update: see the optimistic updates lesson for the rollback rules.

Long drafts deserve protection. Warn on leaving the page with unsaved changes (the beforeunload event), and for long text consider saving the draft to localStorage keyed by card id, so a crash or an accidental close does not lose ten minutes of writing. Controlled vs uncontrolled inputs, validation timing, and schema validation are covered in the forms at scale lesson.

Stream state: true for a moment

The last kind arrives on its own, without the user asking. Boardly shows the faces of teammates viewing the board, their cursors as they move, a "Priya is typing" hint on a card, and a live badge when someone moves a card. All of it is pushed over a WebSocket or server-sent events.

Stream state is pushed data whose value is only true right now and that may change many times a second. Its defining traits are a high rate and a short life. Nobody stores yesterday's cursor positions, and a cursor update that is 2 seconds late is worse than useless.

Two kinds of pushed messages

Not every pushed message is stream state. Split what arrives on the socket into two groups, because they go to different homes.

• Changes to stored data, such as "card c17 moved to Done" or "a comment was added". The truth is in the database; the push is only a fast notice. Write it into the server-state cache (patch the entry, or invalidate the key so it refetches). Then every view of that card updates, and a reload shows the same thing.
• Ephemeral signals, such as cursor positions, presence, and typing hints. They are never stored in a database. Keep them in a small, separate store built for a high rate, and let them expire: a cursor not updated for 5 seconds disappears, a typing hint clears after 3 seconds.

The rate problem

Ten teammates moving their mouse, each sending 20 updates a second, is 200 messages a second. If each one goes through a global store and every subscriber re-renders, the main thread spends its time rendering cursors and the user's own typing starts to lag. That is the "slow typing" bug from the first chapter, and it shows up as a poor INP (Interaction to Next Paint, the Web Vital that measures how fast the page responds to input).

The fix is to separate receiving from rendering. Messages land in a plain buffer (a Map from user id to the latest position) with no re-render. Once per animation frame (usually 60 times a second, more on high refresh rate screens), the cursor layer reads the latest value for each user and draws.

Older values in between are simply overwritten. Only the cursor layer subscribes, so the board and the search box never re-render for a cursor.

const latest = new Map<string, { x: number; y: number; at: number }>();
let scheduled = false;

socket.addEventListener("message", (event) => {
  const msg = JSON.parse(event.data);
  if (msg.type !== "cursor") return handleDataChange(msg); // goes to the query cache
  latest.set(msg.userId, { x: msg.x, y: msg.y, at: Date.now() });
  if (!scheduled) {
    scheduled = true;
    requestAnimationFrame(() => {
      scheduled = false;
      drawCursors(latest); // one paint for any number of messages
    });
  }
});

Senders help too: throttle cursor updates on the client to about 15 to 30 per second, and send nothing while the mouse is still. The receiver can smooth the gaps by animating between positions. The presence and live cursors lesson goes further.

When the stream breaks

Streams drop: laptops sleep, trains go into tunnels. Ephemeral signals are easy: clear them all on disconnect and let them rebuild after reconnect.

Changes to stored data are harder, because any card move that happened while offline was missed. The safe move on reconnect is to refetch (invalidate) the board's server-state entries, or ask the server for every change since the last event id. See the WebSockets and server-sent events lessons for reconnection.

Sorting every piece of Boardly

Now put it all together. Below is every piece of state on Boardly's main screen, with its kind, its home, and the reason. Read the reasons more than the answers: in an interview, the reason is what earns the credit.

Lab: sort the state yourself

Drag each piece of Boardly's state into a bucket, or select it and press a bucket button. The lab tells you what goes wrong when a value lands in the wrong home. Several wrong homes "work" on day one; the lab shows which bug they cause later.

Values that change kind

A value can move from one kind to another during its life, and the moment it moves is where bugs hide. Name the hand-offs in your design.

• Server to form: opening the editor copies the server value into a draft, once.
• Form to server: Save turns the draft into a mutation; on success the cache updates and the draft is cleared.
• URL to server: the filters in the URL become part of the query key, which picks the server data to show.
• Stream to server: a pushed change patches or invalidates the cache.
• Client UI to server: a preference the user wants on every device is saved as a settings record.

Gray areas and how to decide

Some values honestly fit two kinds, and saying so in an interview is a good sign. The right answer depends on a product question, so ask it.

• The selected cards (multi-select). Usually client UI state, because nobody shares a selection. If bulk actions should survive a reload, it could go in the URL, but a long list of ids makes ugly links.
• The current page of an infinite list. Pages loaded so far are server state in the cache. Which page the user is on can be URL state for a paged table (?page=3) but is usually not for an infinite feed. The pagination lesson discusses this.
• A board's column widths. Client UI preference if personal, server state if the board owner sets them for the whole team.
• The wizard step in a multi-step form. Form state if a reload may restart it; URL state (?step=3) if Back should move between steps.

Conflating kinds: the most common design flaw

Almost every state bug in a mature frontend is two kinds of state forced into one home, or one value kept in two homes. These mistakes look harmless in a demo, because a demo has one user, one tab, fast Wi-Fi, and no reloads. They surface in production, one support ticket at a time.

The five conflations to look for

A sixth, quieter mistake is storing derived values: keeping doneCount next to the cards, or filteredCards next to cards and filters. Every update must now remember to fix both, and one day it will not. Compute derived values in render, and memoize them (cache the result until the inputs change) only if profiling shows the computation is slow.

Why teams fall into it

Conflation usually starts with a reasonable wish for one place to look, often from tutorials written before server-state libraries were common. It grows because each new feature copies the pattern next to it. Moving server data out of a store after two years means touching every screen, so it pays to choose homes on day one, which is exactly what an interviewer is checking.

Security, performance, and accessibility angles

• Never put secrets or personal data in the URL. URLs are kept in history, server logs, and analytics tools, and a lax referrer policy can send the full URL to other sites in the Referer header. Tokens and emails go elsewhere.
• Treat URL values as untrusted input. Validate them against an allow-list (sort is one of manual, due, title) and fall back to defaults.
• Be careful what you persist. localStorage can be read by any script on the origin, so a cross-site scripting (XSS) bug exposes it. Keep auth tokens out of it, and clear user data on logout, especially on shared computers.
• Server data cached on the client is per user. On logout, clear the query cache so the next person on the same device does not see the last person's board.
• Focus is UI state too. When the open card closes because the URL changed (including via Back), move keyboard focus back to the card that opened it, so keyboard and screen reader users do not lose their place.
• Rate decides re-render cost. Fast-changing values (drag position, cursors, scroll) should not live in state that many components read.

Real products and the interview

The five kinds are not a theory invented for interviews. Look at any well-built product and you can see the split in its address bar and its behavior.

How real products split their state

• GitHub issues keeps the whole search in the query string, for example ?q=is:issue is:open label:bug. Copy the address and a teammate sees the same list. The issues themselves are server data.
• Trello gives every open card its own URL: trello.com/c/, a short id, then a readable version of the card's title. Opening a card from the board changes the address, so a card can be shared and Back closes it.
• Figma and Google Docs show other people's cursors and selections. These are ephemeral: they are not part of the saved document, and they disappear when the person leaves.
• Linear, in talks about its sync engine, has described its client as keeping a local copy of the workspace data that syncs with the server in the background, so most reads do not wait for the network. That is server state with a much stronger cache, not a reason to mix kinds.

When to bring it up

In a frontend system design interview, sort the state right after you sketch the main components and before you discuss the API in detail. It takes two or three minutes and it shapes every later answer: caching follows from server state, routing from URL state, real-time from stream state, and validation from form state.

Draw a small table or five labelled boxes next to your component diagram. List each piece of state with its kind and home. Then point at the hand-offs: "the filters in the URL are part of the cards query key", "live card moves patch the cache", "the editor copies the card once".

What to say, by level

Interview pitfalls

• Opening with a library name ("I'll use Redux") before saying what the state is. Name the kinds first; tools follow.
• Forgetting the URL entirely. Interviewers often follow up with "what happens when I share this link?"
• Treating live updates as a separate data source instead of a way to keep the server-state cache fresh.
• Over-sorting: you do not need to classify every hover flag. Cover the pieces that drive the design.