Frontend Beauty
ESC

Type to search the knowledge base.

React Mental Model

React mental model: UI as a function of state, declarative trees, one-way data flow, and re-render triggers.

beginner3 min read
  • react
  • react-mental

React’s core idea is small and durable: UI = f(state). You describe what the UI should look like for the current props and state; React updates the host tree to match. You do not manually poke the DOM for ordinary UI changes.

Docs: Thinking in React, Managing State.

Declarative, not document scripting

// Declarative
function Inbox({ unread }) {
  return <h1>{unread === 0 ? 'No mail' : `${unread} unread`}</h1>;
}

// Imperative DOM mindset (avoid as default architecture)
// if (unread === 0) title.textContent = 'No mail'; else ...

One-way data flow

Data flows down via props. Events flow up via callbacks. Shared state lifts to a common parent or lives in context/store. Crossing that flow with random global mutation is how apps become unreadable.

What triggers a re-render

  1. setState / reducer dispatch in this component.
  2. Parent re-render (usually).
  3. Context value change if this component reads it.
  4. Remount (key change) — new state.

Re-render is JS work; DOM updates happen only when host output changes (reconciliation).

Effects are for sync, not for “running code”

Effects synchronize with external systems. User-driven logic belongs in event handlers. Derived data belongs in render. That single distinction removes half of “useEffect spaghetti.”

Mental checklist when stuck

  1. What is the source of truth?
  2. Who owns it?
  3. Is this value derived?
  4. Is this an event or a sync with the outside world?
  5. Am I fighting keys/identity?

Interview out-loud

“React is a declarative UI library: components are functions of props and state, data flows down, events up. Re-renders recompute descriptions; reconciliation applies DOM changes. I keep side effects in effects or handlers, not in render, and I design state ownership before wiring APIs.”

Further reading

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Related guides