100 React Interview Questions and Answers (2026)

React lets developers describe a UI as a tree of components and update that UI by changing props or state instead of manually issuing DOM commands.

• Component model: split the interface into reusable, composable pieces.
• Declarative rendering: describe what the UI should look like for the current data.
• Cross-platform model: React itself defines the component model; renderers such as React DOM target specific environments.

React can be used by itself, but production applications often use it through a React framework that adds routing, server rendering, data loading, and build conventions.

A component receives inputs such as props and can use React features such as state and context to calculate the JSX it returns.

function UserCard({ name }) {
  return (
    <article>
      <h2>{name}</h2>
    </article>
  );
}

Modern React documentation teaches function components first. Hooks are designed for function components and cannot be called inside class components.

JSX is not HTML and it is not a separate templating language. It lets rendering logic and markup stay together inside a component.

const user = "Aisha";

export default function Greeting() {
  return <h1>Hello, {user}</h1>;
}

A component must return a single JSX tree. When you do not want an extra DOM wrapper, you can group siblings with a React Fragment.

Props can contain strings, numbers, objects, arrays, functions, or JSX. A component receives a snapshot of its props for each render.

function Avatar({ name, size = 48 }) {
  return <img alt={name} width={size} height={size} />;
}

export default function Profile() {
  return <Avatar name="Ada" size={64} />;
}

Both props and state should be treated as immutable snapshots for a particular render.

function Card({ children }) {
  return <section className="card">{children}</section>;
}

export default function Page() {
  return (
    <Card>
      <h2>Account</h2>
      <button>Save</button>
    </Card>
  );
}

The Card component does not need to know which exact child elements it wraps. This makes wrapper and layout components highly reusable.

Use state when a component needs to remember information that can change over time, such as an input value, selected tab, or whether a modal is open.

• Persistent across renders: local variables reset when the function runs again, state does not.
• Private to a component instance: rendering the same component twice creates independent state for each position.
• Updated through React: use a setter instead of mutating the state value directly.

import { useState } from "react";

export default function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

count

The state value for the current render

setCount

The setter used to request the next state

0

The initial state used on the first render

function Counter() {
  const [count, setCount] = useState(0);

  function handleClick() {
    setCount(count + 1);
    console.log(count);
  }

  return <button onClick={handleClick}>{count}</button>;
}

0

Each render receives its own state snapshot. Calling the setter queues an update, but it does not rewrite the count variable inside the event handler that is already running.

• Local state update: a setter such as setCount can schedule a render.
• Parent rendering: by default, rendered child components are evaluated again with the parent's current props.
• Context update: components reading that context receive the new value and render again.

A React render does not automatically mean the DOM changes. React can render a component, compare the result, and commit no DOM update if nothing visible changed.

A render can happen without producing a DOM mutation. This distinction is essential when debugging repeated renders or performance.

export default function SaveButton() {
  function handleClick() {
    console.log("Saved");
  }

  return <button onClick={handleClick}>Save</button>;
}

React event props use names such as onClick and onChange. Event handlers are the right place for side effects caused by a specific user action.

function Status({ isLoggedIn }) {
  if (!isLoggedIn) {
    return <LoginButton />;
  }

  return <Dashboard />;
}

• if / early return: useful when whole branches differ.
• condition ? A : B: useful for choosing between two JSX expressions.
• condition && A: useful when an element is optional.
• return null: render nothing from that component.

const users = [
  { id: "u1", name: "Mina" },
  { id: "u2", name: "Ravi" },
];

export default function UserList() {
  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

React does not introduce a special loop syntax for JSX. You usually transform arrays with normal JavaScript methods such as map() and filter().

A good key comes from the data itself, such as a database ID. Keys must be unique among siblings and should remain stable between renders.

{todos.map((todo) => (
  <TodoItem key={todo.id} todo={todo} />
))}

Prefer a stable ID from the data. Generating keys with Math.random() during render is even worse because every render creates new identities.

import { Fragment } from "react";

export default function Name() {
  return (
    <>
      <dt>First name</dt>
      <dd>Ada</dd>
    </>
  );
}

The short syntax <>...</> is convenient when no Fragment key is needed. Use the explicit <Fragment key={...}> form when rendering keyed fragments in a list.

The terms also apply more broadly to component design: a component is more controlled when important behavior is driven by props from its parent.

import { useState } from "react";

export default function SearchBox() {
  const [query, setQuery] = useState("");

  return (
    <input
      value={query}
      onChange={(event) => setQuery(event.target.value)}
      placeholder="Search"
    />
  );
}

For a controlled text input, React state is the source of truth. Checkboxes and radio buttons are controlled with checked rather than their text value.

When sibling components must stay synchronized, storing separate copies of the same state creates duplication. Move the state to their common parent and pass values and handlers down as props.

function Accordion() {
  const [activeId, setActiveId] = useState(null);

  return (
    <>
      <Panel id="a" activeId={activeId} onSelect={setActiveId} />
      <Panel id="b" activeId={activeId} onSelect={setActiveId} />
    </>
  );
}

• Parent owns data: the parent decides the current value.
• Data flows down: children receive current values through props or context.
• Events communicate intent: children can call handlers supplied by the owner to request an update.

This model makes it easier to identify the single source of truth for each piece of application state.

• useState: component state.
• useEffect: synchronization with external systems.
• useRef: mutable values or DOM references that do not trigger rendering.
• useContext: reads and subscribes to a context value.

Custom Hooks let you combine built-in Hooks into reusable logic. Their names conventionally begin with use.

• Top level: do not call ordinary Hooks inside loops, conditions, nested callbacks, or after conditional returns.
• React functions: call Hooks from function components or custom Hooks, not ordinary JavaScript functions or class components.
• Static order: React relies on stable Hook call ordering to associate state with each call.

The React use() API has special calling rules and is an exception to some ordinary Hook restrictions, so avoid overgeneralizing the rule to every function beginning with use.

Typical external systems include network connections, browser APIs, subscriptions, timers, analytics integrations, or third-party widgets.

useEffect(() => {
  const connection = createConnection(roomId);
  connection.connect();

  return () => connection.disconnect();
}, [roomId]);

Dependencies should include the reactive values used by the Effect. In development Strict Mode, React can run an extra setup-and-cleanup cycle to expose missing cleanup logic.

import { useRef } from "react";

function Search() {
  const inputRef = useRef(null);

  function focusSearch() {
    inputRef.current?.focus();
  }

  return (
    <>
      <input ref={inputRef} />
      <button onClick={focusSearch}>Focus</button>
    </>
  );
}

• DOM access: focus, scroll, or measure an element.
• Mutable non-visual value: store timer IDs or other values that should survive renders without changing JSX.

Both preserve information across renders, but only state participates directly in React's declarative rendering model.

import { createContext, useContext } from "react";

const ThemeContext = createContext("light");

function Toolbar() {
  const theme = useContext(ThemeContext);
  return <button className={theme}>Save</button>;
}

Context is useful for values that are needed by many components at different depths, such as theme, locale, or authenticated-user information.

When props, state, or context changes, React renders the next element tree. React then matches that result with the previous tree and commits the required changes to the host environment such as the browser DOM.

• Element/component type: helps React decide whether an existing subtree represents the same kind of UI.
• Keys: help React preserve identity among siblings when collections change.
• Stable position and identity: influence whether component state is preserved or reset.

Calling a state setter does not immediately mutate the state variable from the current render. React queues the update and normally processes the queued work after the event handler has finished.

• Performance: several related updates can be handled in one render instead of producing a partially updated UI after every setter call.
• Snapshot behavior: code still sees the state values captured by the render that created the current event handler.
• Intentional events: separate user interactions such as separate clicks are handled independently rather than being merged into one logical event.

function Counter() {
  const [count, setCount] = useState(0);

  function addThree() {
    setCount(c => c + 1);
    setCount(c => c + 1);
    setCount(c => c + 1);
  }

  return <button onClick={addThree}>{count}</button>;
}

Each updater receives the result of the previous queued update. This makes setCount(c => c + 1) reliable even when several increments are queued from the same event.

function Counter() {
  const [count, setCount] = useState(0);

  function handleClick() {
    setCount(count + 1);
    setCount(count + 1);
    setCount(count + 1);
  }

  return <button onClick={handleClick}>{count}</button>;
}

After one click:
1

During this handler, count is still 0. Each call therefore queues a request equivalent to replacing the state with 1, rather than adding three independent increments.

function Counter() {
  const [count, setCount] = useState(0);

  function handleClick() {
    setCount(c => c + 1);
    setCount(c => c + 1);
    setCount(c => c + 1);
  }

  return <button onClick={handleClick}>{count}</button>;
}

After one click:
3

React processes the updater queue in order: 0 becomes 1, then 2, then 3. Updater functions should be pure because React may call them more than once in development to detect mistakes.

function Profile() {
  const [user, setUser] = useState({
    name: "Ava",
    skills: ["React"]
  });

  function addSkill() {
    setUser(current => ({
      ...current,
      skills: [...current.skills, "TypeScript"]
    }));
  }

  return <button onClick={addSkill}>{user.skills.length}</button>;
}

• Objects: use object spread or another immutable transformation to create a new reference.
• Arrays: prefer methods such as map, filter, concat, or spread instead of mutating methods such as push or splice on state.
• Nested data: copy every changed level, or use an abstraction such as Immer if the state shape makes immutable updates cumbersome.

function Cart({ items }) {
  // Prefer deriving this during render:
  const total = items.reduce((sum, item) => sum + item.price, 0);

  return <strong>Total: {total}</strong>;
}

Two state variables that represent the same underlying fact can drift apart. A useful rule is to store the minimal source of truth and derive the rest during rendering.

A reducer does not make state global. useReducer() still manages state for the component instance unless you deliberately expose it through props or context.

function tasksReducer(state, action) {
  switch (action.type) {
    case "added":
      return [
        ...state,
        { id: action.id, text: action.text, done: false }
      ];
    case "toggled":
      return state.map(task =>
        task.id === action.id
          ? { ...task, done: !task.done }
          : task
      );
    default:
      return state;
  }
}

• Pure transition: same state + action should produce the same next state.
• No side effects: API calls, analytics, timers, and DOM work belong outside the reducer.
• Action intent: actions should describe meaningful events such as added or toggled rather than hide arbitrary mutations.

function useOnlineStatus() {
  const [isOnline, setIsOnline] = useState(true);

  useEffect(() => {
    const online = () => setIsOnline(true);
    const offline = () => setIsOnline(false);

    window.addEventListener("online", online);
    window.addEventListener("offline", offline);

    return () => {
      window.removeEventListener("online", online);
      window.removeEventListener("offline", offline);
    };
  }, []);

  return isOnline;
}

Custom Hooks let components reuse logic without introducing another visual component into the tree.

Calling the same custom Hook twice behaves like calling built-in Hooks twice: each call belongs to the component instance and has its own state slots.

Shared automatically

The Hook implementation and behavior

Not shared automatically

useState/useReducer state created by each Hook call

Can be shared deliberately

Context, an external store, URL state, server cache, or another shared data source

function ChatRoom({ roomId }) {
  useEffect(() => {
    const connection = createConnection(roomId);
    connection.connect();

    return () => {
      connection.disconnect();
    };
  }, [roomId]);

  return <h1>{roomId}</h1>;
}

1. The component commits with the current roomId.
2. The Effect starts the connection for that room.
3. If roomId changes, React runs the previous cleanup.
4. React starts the Effect again using the new roomId.
5. When the component is removed, cleanup runs for the active synchronization.

Props, state, and values calculated inside the component are reactive values because they can change between renders. If an Effect reads them, they generally belong in its dependency list.

No dependency array

Effect is eligible to run after every commit

Empty array []

Effect has no reactive dependencies

[a, b]

Effect re-synchronizes when a or b changes

function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const id = setInterval(() => {
      console.log(count);
    }, 1000);

    return () => clearInterval(id);
  }, []); // count is read but omitted

  return <button onClick={() => setCount(c => c + 1)}>{count}</button>;
}

The interval callback was created by the render where count had its old value. Possible fixes depend on the intent: include the reactive dependency, use an updater when updating state from previous state, or use an Effect Event when the logic should read the latest value without re-synchronizing the external subscription.

function ChatRoom({ roomId, muted }) {
  const onConnected = useEffectEvent(() => {
    if (!muted) {
      showNotification("Connected");
    }
  });

  useEffect(() => {
    const connection = createConnection(roomId);
    connection.on("connected", onConnected);
    connection.connect();

    return () => connection.disconnect();
  }, [roomId]);

  return <h1>{roomId}</h1>;
}

The connection is reactive to roomId, but the notification can read the latest muted value without reconnecting merely because the preference changed.

If sending a POST request should happen because the user clicked Submit, keep it in the submit handler. If a connection should exist whenever a particular roomId is rendered, an Effect expresses that synchronization.

• Render checks: pure component logic may be invoked an extra time in development.
• Effect checks: React can run an extra setup -> cleanup -> setup cycle to expose missing cleanup.
• Ref callback checks: callback refs can also receive extra setup/cleanup checks.
• Production: these Strict Mode checks do not add the same duplicate behavior to the production build.

The goal is not to make developers add flags such as didRun.current to suppress the second call. The goal is to make rendering pure and synchronization cleanup correct.

function Messenger({ contact }) {
  return (
    <Chat
      key={contact.id}
      contact={contact}
    />
  );
}

Using key outside lists is sometimes useful when changing business identity should deliberately create a fresh component instance—for example, clearing a message draft when switching recipients.

function Parent() {
  const [count, setCount] = useState(0);

  // Avoid defining component types here.
  function Form() {
    const [text, setText] = useState("");
    return <input value={text} onChange={e => setText(e.target.value)} />;
  }

  return (
    <>
      <button onClick={() => setCount(c => c + 1)}>{count}</button>
      <Form />
    </>
  );
}

Move Form to module scope so its component type remains stable across Parent renders.

const Row = memo(function Row({ item }) {
  return <li>{item.name}</li>;
});

• Can skip: a parent-driven render when props compare equal.
• Cannot skip: updates caused by the memoized component's own state.
• Cannot skip: updates from context values that the component reads.
• Requirement: rendering must already be pure; memo is an optimization, not a correctness tool.

function ProductList({ products, query }) {
  const visibleProducts = useMemo(
    () => expensiveFilter(products, query),
    [products, query]
  );

  return <Results items={visibleProducts} />;
}

• Expensive calculation: avoid recomputing work when its inputs rarely change.
• Stable prop value: preserve an object/array identity passed to a memoized child when that stability actually matters.
• Hook dependency: preserve a value whose identity is intentionally used by another Hook.

function ProductPage({ productId }) {
  const handleBuy = useCallback(() => {
    purchase(productId);
  }, [productId]);

  return <MemoizedBuyButton onBuy={handleBuy} />;
}

Creating a new JavaScript function is usually cheap. The benefit comes when a stable function identity prevents downstream work such as re-rendering a memoized child or re-synchronizing an Effect.

All three are performance tools. Code should remain correct if the optimization is removed.

const Results = memo(function Results({ options }) {
  return <pre>{JSON.stringify(options)}</pre>;
});

function Search({ query }) {
  // New object on every render:
  const options = { query, limit: 20 };

  return <Results options={options} />;
}

• First: confirm the re-render is actually expensive with profiling.
• Then: inspect prop identities and whether the child also reads changing context or has its own state.
• If necessary: restructure props, memoize a meaningful value, or rely on React Compiler when enabled.

The compiler analyzes components and Hooks under the Rules of React and can generate memoization that skips unnecessary cascading renders and repeated calculations.

• New compiler-enabled code: prefer clear React code first and rely on automatic memoization where appropriate.
• Existing manual memoization: do not delete it blindly; removal can change compilation output or performance behavior.
• Escape hatch: useMemo and useCallback still exist when you need precise control, especially around identity-sensitive dependencies.

function AppProvider({ children }) {
  const [user, setUser] = useState(null);

  const value = { user, setUser };

  return (
    <AuthContext value={value}>
      {children}
    </AuthContext>
  );
}

• Provider value identity: a newly created object can represent a changed context value on each provider render.
• Large contexts: unrelated consumers may update together when one field changes.
• Design options: keep providers focused, split independent contexts, separate state from dispatch when useful, and profile before adding memoization.

Common Context examples include theme, current account, routing-like ambient data, and shared state for a subtree. But prop drilling alone is not proof that every value belongs in Context.

const TasksContext = createContext(null);
const TasksDispatchContext = createContext(null);

function TasksProvider({ children }) {
  const [tasks, dispatch] = useReducer(tasksReducer, initialTasks);

  return (
    <TasksContext value={tasks}>
      <TasksDispatchContext value={dispatch}>
        {children}
      </TasksDispatchContext>
    </TasksContext>
  );
}

Splitting state context from dispatch context can make dependencies clearer and lets components that only dispatch avoid reading the state value.

function PasswordField() {
  const hintId = useId();

  return (
    <>
      <input
        type="password"
        aria-describedby={hintId}
      />
      <p id={hintId}>Use at least 12 characters.</p>
    </>
  );
}

The main use case is accessibility relationships and generated IDs that need to be safe across React's rendering model.

function SearchInput({ ref }) {
  const inputRef = useRef(null);

  useImperativeHandle(ref, () => ({
    focus() {
      inputRef.current?.focus();
    },
    select() {
      inputRef.current?.select();
    }
  }), []);

  return <input ref={inputRef} />;
}

• Good fit: focus, scrolling, text selection, imperative animation, or integration with non-React APIs.
• Prefer props: when the behavior can be expressed declaratively, such as isOpen, value, or selected.

function Modal({ children }) {
  return createPortal(
    <div className="modal">{children}</div>,
    document.body
  );
}

• Typical uses: modals, dialogs, tooltips, overlays, and integration with DOM containers outside the normal parent element.
• React relationship: the portal child still receives context from its React ancestors.
• Physical DOM: only the DOM placement changes.

function App() {
  return (
    <div onClick={() => console.log("App clicked")}>
      <Modal>
        <button>Save</button>
      </Modal>
    </div>
  );
}

The button may be rendered under document.body in the DOM, but it is still a child of App in the React tree.

const MarkdownPreview = lazy(
  () => import("./MarkdownPreview.jsx")
);

function Editor() {
  return (
    <Suspense fallback={<Spinner />}>
      <MarkdownPreview />
    </Suspense>
  );
}

The lazy component suspends while its module is loading, so a surrounding Suspense boundary can render fallback UI.

function Page() {
  return (
    <Suspense fallback={<ArticleSkeleton />}>
      <Article />
    </Suspense>
  );
}

• Code loading: a component declared with lazy can activate the boundary while its module loads.
• Suspense-enabled data: supported framework/data mechanisms can also suspend during rendering.
• Boundary placement: determines how much of the interface is replaced or revealed together.

A lazy import that is still loading is handled by Suspense. If that lazy import's loading promise rejects, the error can be handled by the nearest Error Boundary.

class ErrorBoundary extends React.Component {
  state = { hasError: false };

  static getDerivedStateFromError() {
    return { hasError: true };
  }

  componentDidCatch(error, info) {
    reportError(error, info);
  }

  render() {
    if (this.state.hasError) {
      return <Fallback />;
    }
    return this.props.children;
  }
}

React's built-in class lifecycle APIs getDerivedStateFromError and componentDidCatch are the traditional primitives for implementing an Error Boundary.

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    const controller = new AbortController();

    async function load() {
      try {
        const response = await fetch(
          `/api/users/${userId}`,
          { signal: controller.signal }
        );
        const data = await response.json();
        setUser(data);
      } catch (error) {
        if (error.name !== "AbortError") {
          throw error;
        }
      }
    }

    load();
    return () => controller.abort();
  }, [userId]);

  return <Profile user={user} />;
}

When userId changes, cleanup aborts the previous request before the Effect starts synchronization for the new ID. Another valid pattern is to mark the old request as ignored if the underlying API cannot be cancelled.

The important property is that rendering can be interruptible. React may begin calculating a new tree, pause that work when something more urgent arrives, and continue or restart later.

• Render phase: React calculates what the UI should look like and may interrupt this work.
• Commit phase: React applies the finished result to the host environment; it does not commit a half-finished tree.
• User experience: urgent input can remain responsive while expensive non-urgent UI is prepared in the background.

function Tabs() {
  const [tab, setTab] = useState("overview");
  const [isPending, startTransition] = useTransition();

  function selectTab(nextTab) {
    startTransition(() => {
      setTab(nextTab);
    });
  }

  return (
    <>
      <TabButtons onSelect={selectTab} />
      {isPending && <span>Updating…</span>}
      <TabContent tab={tab} />
    </>
  );
}

The update inside startTransition() is treated as non-urgent, so React can interrupt it to handle more urgent work such as typing or another interaction.

console.log("Before");

startTransition(() => {
  console.log("Inside");
});

console.log("After");

Before
Inside
After

The function passed to startTransition() runs immediately. React's special behavior applies to state updates scheduled during that call, not to the execution timing of normal statements like console.log().

If a component needs to dim a tab, disable navigation controls, or show inline pending feedback, useTransition() is usually more convenient.

function SearchPage() {
  const [query, setQuery] = useState("");
  const [resultsQuery, setResultsQuery] = useState("");
  const [isPending, startTransition] = useTransition();

  function handleChange(event) {
    const nextQuery = event.target.value;

    setQuery(nextQuery); // urgent: controls the input

    startTransition(() => {
      setResultsQuery(nextQuery); // non-urgent
    });
  }

  return (
    <>
      <input value={query} onChange={handleChange} />
      <Results query={resultsQuery} />
    </>
  );
}

React requires the state controlling the input's value to track each keystroke immediately. The expensive result view is the part that can be deprioritized.

A deferred value may lag behind the current value while React renders the newer version in the background. It does not automatically reduce network requests.

function Router() {
  const [page, setPage] = useState("/");

  function navigate(nextPage) {
    startTransition(() => {
      setPage(nextPage);
    });
  }

  return (
    <Suspense fallback={<FullPageSpinner />}>
      <Page page={page} navigate={navigate} />
    </Suspense>
  );
}

• Urgent update: if visible content suspends, the closest boundary may show its fallback immediately.
• Transition update: React can keep already revealed content visible while preparing the replacement.
• New nested boundaries: newly introduced Suspense boundaries may still show their own fallbacks rather than blocking the whole transition.

function Comments({ commentsPromise, show }) {
  if (!show) {
    return null;
  }

  const comments = use(commentsPromise);

  return comments.map(comment => (
    <p key={comment.id}>{comment.text}</p>
  ));
}

• Promise: a pending Promise suspends; a resolved Promise provides its value; a rejection propagates to error handling.
• Context: use can read the nearest Context value similarly to useContext.
• Calling rules: use must still be called from a Component or Hook, but it may appear conditionally or in loops.

function Albums() {
  // Avoid: a new Promise is created every render.
  const albums = use(fetch("/api/albums"));

  return <AlbumList albums={albums} />;
}

The component needs a stable resource identity so React can retry rendering against the same asynchronous work instead of continuously discovering a brand-new pending Promise.

function RenameButton({ saveName }) {
  const [isPending, startTransition] = useTransition();

  function rename() {
    startTransition(async () => {
      await saveName("Ada");
    });
  }

  return (
    <button disabled={isPending} onClick={rename}>
      Rename
    </button>
  );
}

Modern React APIs such as useActionState() and useOptimistic() are designed to compose around this Action model.

Because useActionState() passes the previous action result into the next action, multiple dispatched Actions are processed in order rather than being a generic parallel-task primitive.

function LikeButton({ liked, saveLike }) {
  const [optimisticLiked, setOptimisticLiked] =
    useOptimistic(liked);

  function handleClick() {
    startTransition(async () => {
      setOptimisticLiked(true);
      await saveLike();
    });
  }

  return (
    <button onClick={handleClick}>
      {optimisticLiked ? "Liked" : "Like"}
    </button>
  );
}

• Immediate feedback: optimistic state can appear before the server confirms the mutation.
• Canonical value: the normal value remains the source that determines what survives after the Action.
• Failure: if the Action fails and the canonical value never updates, React returns to that canonical value after the Action ends.

function SubmitButton() {
  const { pending } = useFormStatus();

  return (
    <button type="submit" disabled={pending}>
      {pending ? "Saving…" : "Save"}
    </button>
  );
}

function SettingsForm({ action }) {
  return (
    <form action={action}>
      <input name="displayName" />
      <SubmitButton />
    </form>
  );
}

The status object can expose pending, submitted data, the form method, and the active action.

function useOnlineStatus() {
  return useSyncExternalStore(
    subscribe,
    getSnapshot,
    getServerSnapshot
  );
}

function getSnapshot() {
  return navigator.onLine;
}

function subscribe(callback) {
  window.addEventListener("online", callback);
  window.addEventListener("offline", callback);

  return () => {
    window.removeEventListener("online", callback);
    window.removeEventListener("offline", callback);
  };
}

• subscribe: tells React how to listen for store changes and clean up.
• getSnapshot: returns the current immutable snapshot React should render.
• getServerSnapshot: optionally provides the initial server/hydration snapshot.

function getSnapshot() {
  // Wrong: a fresh object every call.
  return {
    todos: store.todos
  };
}

• Stable when unchanged: repeated reads must return the same value while the store has not changed.
• Immutable snapshot: if the underlying store mutates objects, cache an immutable snapshot and only replace it after a real change.
• SSR: getServerSnapshot must produce data that matches the initial client hydration snapshot.

Hydration is not simply 'render React again'. React attempts to attach event handling and component behavior to the existing server-generated structure.

• Nondeterministic values: timestamps, random numbers, locale differences, or unstable IDs generated independently on server and client.
• Browser-only branching: rendering different JSX because window, localStorage, or viewport data exists only on the client.
• Data mismatch: the client hydrates using different initial data from the data used to generate server HTML.
• Invalid markup: browser HTML correction can change the DOM structure before React hydrates it.

Prefer making the initial server and client outputs identical. If something truly cannot match, isolate the difference instead of broadly suppressing hydration warnings.

Suspense boundaries naturally divide the tree into independent hydration units. React can prioritize the pieces needed for visible or user-interacted content instead of treating the page as one all-or-nothing hydration task.

• Server HTML: content can be visible before all client JavaScript is ready.
• Priority: React can focus hydration work on areas that matter to the user first.
• Architecture: Suspense placement therefore affects both loading UX and hydration granularity.

The two technologies can be combined. A framework can render a Server Component tree and also use SSR to produce initial HTML for the overall page.

A common architecture keeps data-heavy, non-interactive regions on the server and introduces Client Component islands only where interaction is needed.

"use client";

import { useState } from "react";

export default function Counter() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(c => c + 1)}>
      {count}
    </button>
  );
}

You do not need to put "use client" in every component file. It defines a boundary; modules imported through that client graph are handled as client-side code by an RSC-compatible bundler.

export async function updateProfile(formData) {
  "use server";

  const name = formData.get("name");
  await db.profile.update({ name });
}

Calling a Server Function from client code involves a network request with serialized arguments and a serialized result. Framework integration creates the client reference and transport.

• Commonly safe: strings, numbers, booleans, null, supported plain data structures, and other values explicitly supported by the RSC serialization contract.
• Functions: ordinary local functions cannot cross the boundary; Server Functions are the special supported function case.
• Design impact: shape server data into client-facing DTO-like values rather than passing arbitrary server objects through the boundary.

This boundary is also useful architecturally: it forces the client-facing contract to be explicit instead of accidentally leaking server implementation details.

function App({ activeTab }) {
  return (
    <>
      <Activity mode={activeTab === "home" ? "visible" : "hidden"}>
        <Home />
      </Activity>

      <Activity mode={activeTab === "posts" ? "visible" : "hidden"}>
        <Posts />
      </Activity>
    </>
  );
}

• Preserve state: hidden content can return with previous local state intact.
• Clean Effects: Effects are cleaned up while the Activity is hidden and re-created when visible.
• Background preparation: hidden content can still be rendered at lower priority so code/data may be ready before reveal.

function VideoPlayer({ src }) {
  const ref = useRef(null);

  useEffect(() => {
    const video = ref.current;

    return () => {
      video?.pause();
    };
  }, []);

  return <video ref={ref} src={src} controls />;
}

When Activity becomes hidden, React cleans up Effects, but the DOM node can remain. Some native elements such as video, audio, and iframe can therefore have behavior that is different from true DOM removal.

function onRender(
  id,
  phase,
  actualDuration,
  baseDuration
) {
  console.log({
    id,
    phase,
    actualDuration,
    baseDuration
  });
}

function App() {
  return (
    <Profiler id="Results" onRender={onRender}>
      <Results />
    </Profiler>
  );
}

actualDuration

Time spent rendering the profiled subtree for the current update

baseDuration

Estimated cost of rendering the subtree without memoization benefits

phase

Whether the measured commit is a mount, update, or nested update

function handleBeforePrint() {
  flushSync(() => {
    setIsPrinting(true);
  });

  // By here, the DOM reflects isPrinting.
  window.print();
}

• Useful when: an external browser or third-party API requires the DOM to reflect a React update synchronously before the next statement.
• Performance cost: it bypasses normal scheduling advantages and may force other pending work to flush.
• Suspense impact: a synchronous flush can cause pending Suspense fallbacks to appear.