React is an open-source JavaScript library created by Facebook for building user interfaces, particularly single-page applications. Its core features are:

• Component-based architecture — UI is split into reusable, self-contained pieces.
• Virtual DOM — React keeps a lightweight in-memory copy of the real DOM and only updates what changed, boosting performance.
• JSX — A syntax extension that lets you write HTML-like code inside JavaScript.
• Unidirectional data flow — Data flows from parent to child via props, making apps easier to debug.
• Hooks — Functions like useState and useEffect that add state and lifecycle behavior to functional components.

JSX (JavaScript XML) is a syntax extension that allows you to write HTML-like markup inside JavaScript files. It is not valid JavaScript — Babel transpiles it into React.createElement() calls at build time.

// JSX
const element = <h1 className="title">Hello, World!</h1>;

// What Babel compiles it to
const element = React.createElement('h1', { className: 'title' }, 'Hello, World!');

JSX makes component code more readable and easier to reason about compared to chained createElement calls.

// Class Component
class Greeting extends React.Component {
  render() {
    return <h1>Hello, {this.props.name}</h1>;
  }
}

// Functional Component (preferred)
function Greeting({ name }) {
  return <h1>Hello, {name}</h1>;
}

Functional components are simpler, use less boilerplate, and since React 16.8 can use Hooks for state and side-effects. Class components require this, lifecycle methods, and are generally more verbose. New code should prefer functional components.

Props (short for properties) are read-only inputs passed from a parent component to a child component. They make components reusable by letting the parent control child behavior/appearance.

function Button({ label, color }) {
  return <button style={{ background: color }}>{label}</button>;
}

// Usage
<Button label="Submit" color="blue" />

Props are immutable inside the child — the child must never modify them directly.

State is mutable data managed inside a component. When state changes, the component re-renders. Props are immutable data passed from outside.

import { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}

Think of props as arguments to a function and state as local variables that persist across renders.

The Virtual DOM is a lightweight JavaScript object tree that mirrors the real DOM. When state or props change, React:

• Renders a new Virtual DOM tree.
• Diffs it against the previous tree (reconciliation).
• Computes the minimal set of real DOM mutations.
• Applies only those changes to the actual browser DOM.

This batched, minimal-update strategy is far faster than naive full-page re-renders.

useState is a Hook that adds local state to a functional component. It returns a tuple: the current value and a setter function.

import { useState } from 'react';

function Toggle() {
  const [isOn, setIsOn] = useState(false);

  return (
    <button onClick={() => setIsOn(prev => !prev)}>
      {isOn ? 'ON' : 'OFF'}
    </button>
  );
}

The functional updater form prev => !prev is preferred when the new value depends on the old one, because React may batch state updates.

useEffect lets you perform side-effects (data fetching, subscriptions, DOM mutations, timers) after render. It runs after the component renders and optionally cleans up before re-running.

import { useState, useEffect } from 'react';

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

  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then(r => r.json())
      .then(setUser);

    // cleanup (runs before next effect or unmount)
    return () => setUser(null);
  }, [userId]); // re-runs only when userId changes

  if (!user) return <p>Loading...</p>;
  return <p>{user.name}</p>;
}

Hooks are functions that let functional components tap into React features that were previously only available in class components.

• useState — local component state
• useEffect — side-effects and lifecycle
• useContext — consume a React context
• useRef — mutable ref object / DOM access
• useMemo — memoize expensive computed values
• useCallback — memoize callback functions
• useReducer — complex state with reducer pattern

Rules of Hooks: only call at the top level, only call inside React functions — never inside conditionals or loops.

The key prop helps React identify which items in a list have changed, been added, or removed during reconciliation. Keys must be stable, unique among siblings, and ideally come from your data (e.g., database IDs).

const items = [{ id: 1, name: 'Alice' }, { id: 2, name: 'Bob' }];

function List() {
  return (
    <ul>
      {items.map(item => (
        <li key={item.id}>{item.name}</li> // ✅ stable, unique
      ))}
    </ul>
  );
}

Avoid using array index as key when the list can be reordered — this causes subtle re-render bugs.

Conditional rendering lets you show or hide UI based on state or props. Common patterns:

function Alert({ isError, message }) {
  // if/else
  if (isError) return <div className="error">{message}</div>;

  // ternary
  return <div>{message ? message : 'No messages'}</div>;

  // short-circuit &&
  return <div>{message && <span>{message}</span>}</div>;
}

React events use camelCase names and receive a SyntheticEvent — a cross-browser wrapper around the native event.

function Form() {
  function handleSubmit(e) {
    e.preventDefault(); // prevent page reload
    console.log('submitted');
  }

  return (
    <form onSubmit={handleSubmit}>
      <input onChange={e => console.log(e.target.value)} />
      <button type="submit">Send</button>
    </form>
  );
}

Fragments let you group multiple elements without adding an extra DOM node. This avoids invalid HTML (e.g., a <tr> inside a <div>) and keeps the DOM clean.

// Short syntax
function Columns() {
  return (
    <>
      <td>Name</td>
      <td>Age</td>
    </>
  );
}

// With key (must use long form)
items.map(item => (
  <React.Fragment key={item.id}>
    <dt>{item.term}</dt>
    <dd>{item.def}</dd>
  </React.Fragment>
))

useRef returns a mutable object { current: value } that persists across renders without causing re-renders when changed.

// Use case 1: access a DOM node
function FocusInput() {
  const inputRef = useRef(null);
  return (
    <>
      <input ref={inputRef} />
      <button onClick={() => inputRef.current.focus()}>Focus</button>
    </>
  );
}

// Use case 2: store a mutable value (e.g. previous state)
function Timer() {
  const timerIdRef = useRef(null);
  const start = () => { timerIdRef.current = setInterval(tick, 1000); };
  const stop  = () => clearInterval(timerIdRef.current);
  // ...
}

Prop drilling happens when you must pass data through many intermediate components just to reach a deeply nested consumer that actually needs it.

// theme has to travel A → B → C even though B doesn't use it
<A theme="dark" />
  <B theme={theme} />    // B just passes it down
    <C theme={theme} />  // C actually uses it

Problems: tight coupling, verbose code, hard to refactor. Solutions include React Context, Redux, Zustand, or component composition.

Context provides a way to share values (theme, auth, locale) across the component tree without prop drilling.

const ThemeContext = React.createContext('light');

function App() {
  return (
    <ThemeContext.Provider value="dark">
      <Toolbar />
    </ThemeContext.Provider>
  );
}

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

Context should be used for low-frequency global data. For high-frequency updates, prefer a state manager to avoid unnecessary re-renders.

When two sibling components need to share state, you lift the state to their closest common ancestor and pass it down as props.

function Parent() {
  const [value, setValue] = useState('');
  return (
    <>
      <Input value={value} onChange={setValue} />
      <Display value={value} />
    </>
  );
}

function Input({ value, onChange }) {
  return <input value={value} onChange={e => onChange(e.target.value)} />;
}

function Display({ value }) {
  return <p>{value}</p>;
}

A controlled component has its form input value driven by React state. A uncontrolled component manages its own state internally via the DOM; you read the value with a ref.

// Controlled
const [text, setText] = useState('');
<input value={text} onChange={e => setText(e.target.value)} />

// Uncontrolled
const inputRef = useRef();
<input ref={inputRef} defaultValue="hello" />
// read: inputRef.current.value

Controlled components give you full control over validation and transformations on every keystroke. Uncontrolled components are simpler for basic forms and integrating with non-React code.

StrictMode is a developer tool that helps you spot potential problems. It intentionally double-invokes render functions, state initializers, and effects (in development) to surface side-effects written incorrectly. It has no effect in production builds.

<React.StrictMode>
  <App />
</React.StrictMode>

Warnings it catches: deprecated API usage, impure render side-effects, unexpected re-render issues, and missing cleanup in effects.

State must be treated as immutable. Always return a new object/array instead of mutating the existing one.

// ❌ Wrong — mutates directly
state.user.name = 'Alice'; setState(state);

// ✅ Correct — spread into new object
setState(prev => ({ ...prev, user: { ...prev.user, name: 'Alice' } }));

// ✅ Array: add item
setItems(prev => [...prev, newItem]);

// ✅ Array: remove item
setItems(prev => prev.filter(item => item.id !== targetId));

// ✅ Array: update item
setItems(prev => prev.map(item => item.id === targetId ? { ...item, done: true } : item));

Both null, undefined, and false render nothing — they are valid children that produce no DOM output. This makes them ideal for conditional rendering.

function Component({ show }) {
  return (
    <div>
      {show && <p>Visible!</p>}  // nothing rendered when show=false
      {null}                            // nothing rendered
      {0}                               // ⚠️ renders "0"! be careful
    </div>
  );
}

Note: the number 0 does render — a common footgun when using count && <Comp />.

// Modern: destructuring defaults
function Button({ label = 'Click me', color = 'blue' }) {
  return <button style={{ color }}>{label}</button>;
}

// Legacy: static property
Button.defaultProps = { label: 'Click me', color: 'blue' };

Destructuring defaults are preferred in modern React since defaultProps may be removed in a future major version.

The children prop contains everything placed between the component’s opening and closing tags, enabling composable wrapper components.

function Card({ children, title }) {
  return (
    <div className="card">
      <h2>{title}</h2>
      {children}
    </div>
  );
}

// Usage
<Card title="Hello">
  <p>I am a child!</p>
</Card>

In React, the style attribute accepts a JavaScript object with camelCased property names and string values (not a CSS string).

const styles = {
  backgroundColor: '#0d1117',
  fontSize: '16px',
  marginTop: 8,          // numbers default to px
  fontWeight: 'bold',
};

<div style={styles}>Styled</div>
// or inline:
<div style={{ color: 'red' }}>Red</div>

React batches multiple state updates in event handlers (and in React 18+, everywhere including async code) into a single re-render for performance.

function Component() {
  const [a, setA] = useState(0);
  const [b, setB] = useState(0);

  function handleClick() {
    setA(1); // batched
    setB(2); // batched
    // → only ONE re-render occurs
  }
}

If you need the current state value based on the previous update, use the functional updater form: setCount(prev => prev + 1).

useReducer is ideal when state transitions depend on the previous state and multiple sub-values change together, or when the next state logic is complex.

const initialState = { count: 0, step: 1 };

function reducer(state, action) {
  switch (action.type) {
    case 'increment': return { ...state, count: state.count + state.step };
    case 'setStep':   return { ...state, step: action.payload };
    default: throw new Error('Unknown action');
  }
}

function Counter() {
  const [state, dispatch] = useReducer(reducer, initialState);
  return (
    <>
      <p>{state.count}</p>
      <button onClick={() => dispatch({ type: 'increment' })}>+</button>
    </>
  );
}

useMemo memoizes the result of an expensive computation, recomputing it only when dependencies change. It prevents unnecessary recalculations on every render.

import { useMemo } from 'react';

function ProductList({ products, filter }) {
  const filtered = useMemo(
    () => products.filter(p => p.category === filter),
    [products, filter]  // only recompute when these change
  );

  return filtered.map(p => <ProductCard key={p.id} product={p} />);
}

Don’t over-optimize — only use useMemo when a profiler shows a real bottleneck. The memoization itself has overhead.

useCallback(fn, deps) memoizes a function reference. It’s equivalent to useMemo(() => fn, deps). Use it when passing callbacks to memoized child components to prevent unnecessary re-renders.

const handleClick = useCallback(() => {
  doSomethingWith(id);
}, [id]); // stable reference unless id changes

// useMemo — memoizes a VALUE
const total = useMemo(() => items.reduce((s, i) => s + i.price, 0), [items]);

// useCallback — memoizes a FUNCTION
const getTotal = useCallback(() => items.reduce((s, i) => s + i.price, 0), [items]);

React.memo is a higher-order component that memoizes a functional component. It skips re-rendering if props haven’t changed (shallow comparison).

const ExpensiveChild = React.memo(function({ value }) {
  console.log('rendered');
  return <div>{value}</div>;
});

// Custom comparator
const MemoComp = React.memo(Comp, (prev, next) => {
  return prev.id === next.id; // return true → skip re-render
});

Works best when paired with useCallback/useMemo for stable prop references.

A custom Hook is a function whose name starts with use and that calls other Hooks. It extracts reusable stateful logic from components.

function useFetch(url) {
  const [data, setData]   = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    let cancelled = false;
    setLoading(true);
    fetch(url)
      .then(r => r.json())
      .then(d => { if (!cancelled) setData(d); })
      .catch(e => { if (!cancelled) setError(e); })
      .finally(() => { if (!cancelled) setLoading(false); });
    return () => { cancelled = true; };
  }, [url]);

  return { data, loading, error };
}

// Usage
const { data, loading } = useFetch('/api/users');

Reconciliation is the algorithm React uses to diff the new Virtual DOM tree against the previous one and determine the minimal set of real DOM changes needed.

Key heuristics:

• Elements of different types produce entirely different trees (full subtree rebuild).
• The developer can hint stable identity with the key prop.
• Same type → React updates props in place, keeping DOM node and children.

React 18 uses the Fiber architecture which makes reconciliation interruptible, enabling concurrent features like Suspense and transitions.

Fiber is React’s internal reconciliation engine (introduced in React 16). It reimplements the reconciler using a linked list of “fiber” units of work, allowing React to pause, resume, abort, and prioritize rendering work.

This enables:

• Concurrent rendering — interruptible renders that keep the UI responsive.
• Suspense & lazy loading — pause rendering until async data or components are ready.
• startTransition — mark non-urgent state updates so urgent updates (typing) stay fast.

React.lazy lets you code-split a component into a separate bundle loaded on demand. Suspense shows a fallback while it loads.

import { lazy, Suspense } from 'react';

const Dashboard = lazy(() => import('./Dashboard'));

function App() {
  return (
    <Suspense fallback={<Spinner />}>
      <Dashboard />
    </Suspense>
  );
}

The browser only downloads the Dashboard bundle when it’s first rendered. Useful for route-level code splitting.

Error Boundaries are class components that catch JavaScript errors in their child tree and display a fallback UI instead of crashing the whole app. They must implement static getDerivedStateFromError or componentDidCatch.

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

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

  componentDidCatch(error, info) {
    logErrorToService(error, info.componentStack);
  }

  render() {
    if (this.state.hasError)
      return <h2>Something went wrong.</h2>;
    return this.props.children;
  }
}

Note: Error boundaries don’t catch errors in event handlers or async code — use regular try/catch for those.

useLayoutEffect fires synchronously after all DOM mutations but before the browser paints. useEffect fires after the paint.

useLayoutEffect(() => {
  // Measure DOM, synchronously update layout
  const rect = ref.current.getBoundingClientRect();
  setWidth(rect.width);
}); // no flicker — runs before browser paint

Use useLayoutEffect when you need to read layout from the DOM and synchronously re-render to prevent visual flicker (e.g., tooltips, measuring elements). For everything else, prefer useEffect to avoid blocking the paint.

Portals render children into a DOM node that exists outside the parent component’s DOM hierarchy, while still keeping them in the React component tree (events bubble normally).

import { createPortal } from 'react-dom';

function Modal({ children }) {
  return createPortal(
    <div className="modal">{children}</div>,
    document.getElementById('modal-root')  // DOM outside app root
  );
}

Common use cases: modals, tooltips, dropdowns — anything that needs to visually escape overflow-hidden or z-index constraints of its parent.

By default, ref cannot be passed as a prop to a functional component. forwardRef lets you expose a ref from a parent to a DOM node inside the child.

const Input = React.forwardRef((props, ref) => (
  <input ref={ref} {...props} />
));

function Parent() {
  const inputRef = useRef();
  return <Input ref={inputRef} />; // ref reaches the <input> DOM node
}

Commonly used in design system libraries to give consumers direct DOM access while keeping internal implementation details abstracted.

// No dependency array → runs after EVERY render
useEffect(() => { console.log('every render'); });

// Empty array [] → runs ONCE after mount
useEffect(() => { console.log('mounted'); }, []);

// With deps → runs on mount AND when any dep changes
useEffect(() => {
  console.log('userId changed');
}, [userId]);

The cleanup function returned from useEffect runs before the next effect execution or on unmount — in all three cases.

function LoginForm() {
  const [fields, setFields] = useState({ email: '', password: '' });
  const [errors, setErrors] = useState({});

  function validate() {
    const e = {};
    if (!fields.email.includes('@')) e.email = 'Invalid email';
    if (fields.password.length < 8) e.password = 'Min 8 chars';
    return e;
  }

  function handleSubmit(e) {
    e.preventDefault();
    const e2 = validate();
    if (Object.keys(e2).length) { setErrors(e2); return; }
    submitToServer(fields);
  }

  const change = field => e =>
    setFields(prev => ({ ...prev, [field]: e.target.value }));

  return (
    <form onSubmit={handleSubmit}>
      <input value={fields.email} onChange={change('email')} />
      {errors.email && <span>{errors.email}</span>}
      <input type="password" value={fields.password} onChange={change('password')} />
      {errors.password && <span>{errors.password}</span>}
      <button type="submit">Login</button>
    </form>
  );
}

The render props pattern involves a component that accepts a function as a prop (or as children), and calls it to determine what to render, sharing logic without inheritance or HOCs.

function MouseTracker({ render }) {
  const [pos, setPos] = useState({ x: 0, y: 0 });
  return (
    <div onMouseMove={e => setPos({ x: e.clientX, y: e.clientY })}>
      {render(pos)}
    </div>
  );
}

// Usage
<MouseTracker render={({ x, y }) => <p>{x}, {y}</p>} />

Hooks have largely replaced render props for sharing logic, but the pattern is still common in libraries like React Router and Formik.

A HOC is a function that takes a component and returns an enhanced component. It’s a compositional pattern for cross-cutting concerns (auth, logging, theming).

function withAuth(WrappedComponent) {
  return function AuthGuard(props) {
    const { isLoggedIn } = useAuth();
    if (!isLoggedIn) return <Redirect to="/login" />;
    return <WrappedComponent {...props} />;
  };
}

const ProtectedDashboard = withAuth(Dashboard);

HOCs should not mutate the wrapped component. Use a display name (AuthGuard.displayName) for better DevTools debugging.

Combining Context and useReducer gives you a lightweight Redux-like global store without external libraries.

const StoreContext = createContext();

function storeReducer(state, action) {
  switch (action.type) {
    case 'LOGIN':  return { ...state, user: action.payload };
    case 'LOGOUT': return { ...state, user: null };
    default: return state;
  }
}

export function StoreProvider({ children }) {
  const [state, dispatch] = useReducer(storeReducer, { user: null });
  return (
    <StoreContext.Provider value={{ state, dispatch }}>
      {children}
    </StoreContext.Provider>
  );
}

export const useStore = () => useContext(StoreContext);

useImperativeHandle customizes the instance value exposed to parent refs via forwardRef, allowing you to expose only a limited API instead of the raw DOM node.

const FancyInput = forwardRef((props, ref) => {
  const inputRef = useRef();

  useImperativeHandle(ref, () => ({
    focus: () => inputRef.current.focus(),
    clear: () => { inputRef.current.value = ''; },
    // DOM node itself is NOT exposed
  }));

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

// Parent can call: ref.current.focus() or ref.current.clear()

import { BrowserRouter, Routes, Route, Link } from 'react-router-dom';

function App() {
  return (
    <BrowserRouter>
      <nav>
        <Link to="/">Home</Link>
        <Link to="/about">About</Link>
        <Link to="/user/42">User</Link>
      </nav>
      <Routes>
        <Route path="/"          element={<Home />}         />
        <Route path="/about"     element={<About />}        />
        <Route path="/user/:id"  element={<UserProfile />}  />
        <Route path="*"          element={<NotFound />}      />
      </Routes>
    </BrowserRouter>
  );
}

function PostList() {
  const [posts, setPosts]   = useState([]);
  const [status, setStatus] = useState('idle'); // idle|loading|success|error
  const [error, setError]   = useState(null);

  useEffect(() => {
    setStatus('loading');
    fetch('/api/posts')
      .then(r => { if (!r.ok) throw new Error(r.statusText); return r.json(); })
      .then(data => { setPosts(data); setStatus('success'); })
      .catch(err => { setError(err.message); setStatus('error'); });
  }, []);

  if (status === 'loading') return <Spinner />;
  if (status === 'error')   return <p>Error: {error}</p>;
  return posts.map(p => <Post key={p.id} post={p} />);
}

React.cloneElement lets you clone a React element and inject additional props or override existing ones, useful in compound component patterns.

function Tabs({ children, activeTab }) {
  return (
    <div>
      {React.Children.map(children, child =>
        React.cloneElement(child, {
          isActive: child.props.id === activeTab
        })
      )}
    </div>
  );
}
// Each Tab child now receives isActive without the parent knowing its internals

Modern alternative: use Context to share state inside compound components without cloneElement.

function Search() {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);

  useEffect(() => {
    if (!query) { setResults([]); return; }
    const timer = setTimeout(() => {
      fetchResults(query).then(setResults);
    }, 300); // 300ms debounce

    return () => clearTimeout(timer); // cancel if query changes
  }, [query]);

  return (
    <>
      <input value={query} onChange={e => setQuery(e.target.value)} />
      {results.map(r => <div key={r.id}>{r.title}</div>)}
    </>
  );
}

React DevTools is a browser extension that adds a Components and Profiler panel to browser DevTools.

• Components panel — inspect the component tree, view props/state/hooks, and highlight re-renders.
• Profiler panel — record a session, then see which components rendered, how long each took (in ms), and why they re-rendered. Flame chart shows the render waterfall.

Workflow: Record → interact with the app → stop recording → look for unexpectedly frequent or slow renders → apply memo, useCallback, or structural fixes as needed.

Compound components are a set of components that work together and share implicit state via Context. The parent manages state; children can access it without explicit props.

const AccordionContext = createContext();

function Accordion({ children }) {
  const [open, setOpen] = useState(null);
  return (
    <AccordionContext.Provider value={{ open, setOpen }}>
      <div>{children}</div>
    </AccordionContext.Provider>
  );
}

function Item({ id, children }) {
  const { open, setOpen } = useContext(AccordionContext);
  return (
    <div>
      <button onClick={() => setOpen(open === id ? null : id)}>Toggle</button>
      {open === id && children}
    </div>
  );
}

Accordion.Item = Item;

// Usage: <Accordion><Accordion.Item id="a">...</Accordion.Item></Accordion>

function InfiniteList() {
  const [items, setItems]   = useState([]);
  const [page, setPage]     = useState(1);
  const sentinelRef         = useRef();

  useEffect(() => {
    fetchPage(page).then(data => setItems(prev => [...prev, ...data]));
  }, [page]);

  useEffect(() => {
    const observer = new IntersectionObserver(([entry]) => {
      if (entry.isIntersecting) setPage(p => p + 1);
    });
    if (sentinelRef.current) observer.observe(sentinelRef.current);
    return () => observer.disconnect();
  }, []);

  return (
    <>
      {items.map(i => <Item key={i.id} data={i} />)}
      <div ref={sentinelRef} /> // invisible bottom sentinel
    </>
  );
}

Code splitting breaks your bundle into smaller chunks loaded on demand, reducing initial bundle size and TTI (Time to Interactive).

• Component-level: React.lazy + dynamic import()
• Route-level: Lazy-load each route component
• Library-level: Webpack/Vite automatically split node_modules

// Route-level splitting
const Home    = lazy(() => import('./routes/Home'));
const Profile = lazy(() => import('./routes/Profile'));

<Suspense fallback={<Spinner/>}>
  <Routes>
    <Route path="/"        element={<Home/>}    />
    <Route path="/profile" element={<Profile/>} />
  </Routes>
</Suspense>

React supports full HTML accessibility attributes with camelCase naming. Key practices:

// aria-* attributes stay hyphenated
<button aria-label="Close modal" aria-expanded={isOpen}>✕</button>

// for/htmlFor association
<label htmlFor="email">Email</label>
<input id="email" type="email" />

// Focus management for modals
useEffect(() => { if (isOpen) closeButtonRef.current?.focus(); }, [isOpen]);

Tools: eslint-plugin-jsx-a11y, React Aria (Adobe), axe-core DevTools extension.

Introduced in React 18, useId generates a stable unique ID that is consistent between server and client renders — avoiding SSR hydration mismatches.

function FormField({ label }) {
  const id = useId(); // e.g. ":r1:"
  return (
    <>
      <label htmlFor={id}>{label}</label>
      <input id={id} />
    </>
  );
}

Do not use useId to generate keys for lists — use data IDs for that.

startTransition marks a state update as non-urgent. React will defer it and keep the UI responsive for urgent updates (like typing).

import { startTransition, useTransition } from 'react';

function Search() {
  const [isPending, startTransition] = useTransition();
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);

  function handleChange(e) {
    setQuery(e.target.value); // urgent — update input immediately
    startTransition(() => {
      setResults(computeResults(e.target.value)); // non-urgent
    });
  }

  return (
    <>
      <input value={query} onChange={handleChange} />
      {isPending ? <Spinner/> : results.map(...)}
    </>
  );
}

The standard stack: Vitest or Jest (test runner) + React Testing Library (RTL) for DOM-focused tests + Playwright/Cypress for end-to-end tests.

// Example RTL test
import { render, screen, fireEvent } from '@testing-library/react';

test('increments counter', () => {
  render(<Counter />);
  expect(screen.getByText('Count: 0')).toBeInTheDocument();
  fireEvent.click(screen.getByRole('button', { name: /increment/i }));
  expect(screen.getByText('Count: 1')).toBeInTheDocument();
});

RTL philosophy: test what the user sees (text, roles) not implementation details (state, refs).

Concurrent rendering (React 18) lets React prepare multiple versions of the UI simultaneously without blocking the main thread. Renders can be interrupted, paused, and resumed based on priority.

Key APIs:

• createRoot — opt into concurrent mode
• startTransition / useTransition — deprioritize non-urgent updates
• useDeferredValue — defer a value to avoid blocking input
• Suspense + data fetching — show fallbacks while async rendering

Benefit: heavy renders (large lists, complex charts) no longer freeze the UI — React keeps urgent interactions (typing, clicking) buttery smooth.

useDeferredValue accepts a value and returns a deferred version that “lags behind” to allow more urgent renders to go first.

function SearchResults({ query }) {
  const deferredQuery = useDeferredValue(query);
  // stale deferredQuery during typing → React renders latest query first
  const results = expensiveFilter(deferredQuery);
  return results.map(r => <Result key={r.id} {...r} />);
}

vs debounce: debounce delays state updates on a fixed timer. useDeferredValue lets React schedule the update based on available CPU time — no artificial delay, and it starts updating as soon as the browser is idle.

With SSR, React renders components to HTML on the server and sends it to the browser. The client then “hydrates” — attaching event listeners to the existing HTML without re-rendering.

// Server (Node.js)
import { renderToString } from 'react-dom/server';
const html = renderToString(<App />);
res.send(`<html><body><div id="root">${html}</div></body></html>`);

// Client
import { hydrateRoot } from 'react-dom/client';
hydrateRoot(document.getElementById('root'), <App />);

Benefits: faster FCP, SEO-friendly. Drawbacks: TTFB increases, server load, hydration complexity. Frameworks: Next.js, Remix.

React Server Components (introduced in React 18, popularized by Next.js 13+ App Router) run exclusively on the server. They can access databases and file systems directly, never ship JS to the client, and reduce bundle size.

• Server Components — async, no state/hooks, zero client JS
• Client Components — 'use client' directive, can use hooks and events
• Shared Components — can render as either depending on where they’re imported

// app/page.tsx — Server Component (default in Next.js 13+)
async function Page() {
  const data = await db.query('SELECT * FROM posts'); // runs on server only
  return data.map(post => <PostCard key={post.id} post={post} />);
}

Hydration is the process of attaching React’s event system to server-rendered HTML. React walks the existing DOM and matches it against the Virtual DOM tree. If they don’t match, React throws a hydration error and falls back to client rendering.

Common causes of hydration mismatch:

• Rendering Date.now() or Math.random() differently server vs client
• Using typeof window to conditionally render
• Third-party scripts modifying the DOM before React hydrates
• Invalid HTML nesting (e.g. <p><div></div></p>)

Fix: use suppressHydrationWarning for intentional mismatches (e.g., timestamps), or defer rendering until client with useEffect.

A component “suspends” by throwing a Promise. React catches it, shows the nearest Suspense fallback, and retries rendering the component when the Promise resolves.

// Library creates a "resource" that throws a Promise
function wrapPromise(promise) {
  let status = 'pending', result;
  const p = promise.then(d => { status = 'success'; result = d; })
                   .catch(e => { status = 'error'; result = e; });
  return { read() {
    if (status === 'pending')  throw p;
    if (status === 'error')    throw result;
    return result;
  }};
}

// Component using the resource
function UserProfile({ resource }) {
  const user = resource.read(); // throws Promise if not ready
  return <div>{user.name}</div>;
}

In practice, frameworks like Next.js and libraries like TanStack Query implement this for you.

Virtualization renders only the visible rows, keeping DOM nodes constant regardless of list size. Great for lists of 10,000+ items.

const ROW_HEIGHT = 40;

function VirtualList({ items }) {
  const [scrollTop, setScrollTop] = useState(0);
  const containerHeight = 400;
  const totalHeight = items.length * ROW_HEIGHT;

  const startIndex = Math.floor(scrollTop / ROW_HEIGHT);
  const visibleCount = Math.ceil(containerHeight / ROW_HEIGHT) + 1;
  const visibleItems = items.slice(startIndex, startIndex + visibleCount);

  return (
    <div
      style={{ height: containerHeight, overflowY: 'auto', position: 'relative' }}
      onScroll={e => setScrollTop(e.target.scrollTop)}
    >
      <div style={{ height: totalHeight }}>
        {visibleItems.map((item, i) => (
          <div
            key={item.id}
            style={{
              position: 'absolute',
              top: (startIndex + i) * ROW_HEIGHT,
              height: ROW_HEIGHT,
            }}
          >
            {item.name}
          </div>
        ))}
      </div>
    </div>
  );
}

In production, use react-window or @tanstack/react-virtual.

Flux is a unidirectional data-flow pattern from Facebook: Action → Dispatcher → Store → View → Action. Redux is an opinionated Flux implementation with a single store, pure reducer functions, and a rich middleware ecosystem.

// Redux flow
store.dispatch({ type: 'counter/increment' }); // Action
// Reducer: (state, action) => newState
// Subscribers re-render

Redux Toolkit (RTK) is now the official, recommended way to use Redux — it uses Immer internally so you can “mutate” state in reducers, and createSlice handles action type boilerplate.

Zustand is a minimal, hook-based state manager. It has almost no boilerplate and works outside React components too.

import { create } from 'zustand';

const useStore = create(set => ({
  count: 0,
  increment: () => set(state => ({ count: state.count + 1 })),
}));

function Counter() {
  const { count, increment } = useStore();
  return <button onClick={increment}>{count}</button>;
}

vs Redux: Zustand is far less boilerplate, no Provider needed, subscribes components to only the slice of state they use. Redux RTK remains better for large teams needing strict conventions, time-travel debugging, and powerful middleware.

Systematic approach:

• Profile first — use React DevTools Profiler to find offending components before guessing.
• Memoize components — React.memo skips re-renders when props are reference-equal.
• Stable references — useCallback / useMemo prevent new object/function refs on each render.
• Split Context — separate frequently-changing from infrequently-changing context values.
• Colocate state — push state down; only subtrees that need it re-render.
• Virtualize lists — react-window renders only visible rows.
• Lazy load — code-split heavy sections, images, data.
• Transitions — wrap non-urgent updates in startTransition.

React 18 batches all state updates automatically (even in setTimeout and Promises). flushSync forces React to flush pending updates synchronously inside the callback — useful when you need DOM measurements immediately after a state update.

import { flushSync } from 'react-dom';

flushSync(() => {
  setItems([..items, newItem]);
});
// DOM is updated HERE, before the next line
listRef.current.lastChild.scrollIntoView();

Use sparingly — overuse hurts performance by defeating batching.

function DnDList({ initialItems }) {
  const [items, setItems] = useState(initialItems);
  const dragIndex = useRef(null);

  function handleDragStart(index) { dragIndex.current = index; }

  function handleDrop(dropIndex) {
    const updated = [...items];
    const [removed] = updated.splice(dragIndex.current, 1);
    updated.splice(dropIndex, 0, removed);
    setItems(updated);
    dragIndex.current = null;
  }

  return (
    <ul>
      {items.map((item, i) => (
        <li
          key={item.id}
          draggable
          onDragStart={() => handleDragStart(i)}
          onDragOver={e => e.preventDefault()}
          onDrop={() => handleDrop(i)}
        >
          {item.label}
        </li>
      ))}
    </ul>
  );
}

For production: use @dnd-kit/core or react-beautiful-dnd for accessibility, touch support, and animation.

A stale closure occurs when a callback captures an old value from a previous render and doesn’t see the current state/props.

// ❌ Bug — count is stale inside setInterval callback
useEffect(() => {
  const id = setInterval(() => {
    setCount(count + 1); // always reads count=0
  }, 1000);
  return () => clearInterval(id);
}, []); // empty deps — effect never re-runs

// ✅ Fix — use functional updater
setCount(prev => prev + 1); // prev is always fresh

// ✅ Alternative — use a ref to track latest value
const countRef = useRef(count);
countRef.current = count;
// inside callback: use countRef.current

An optimistic update applies a change immediately in the UI before the server confirms it, then rolls back if the server returns an error.

async function toggleLike(postId) {
  // 1. Optimistically update UI
  setPosts(prev => prev.map(p =>
    p.id === postId ? { ...p, liked: !p.liked } : p
  ));

  try {
    await api.toggleLike(postId); // 2. Persist on server
  } catch {
    // 3. Roll back on failure
    setPosts(prev => prev.map(p =>
      p.id === postId ? { ...p, liked: !p.liked } : p // toggle back
    ));
    toast.error('Failed to update like');
  }
}

React 19 introduced useOptimistic for a built-in, first-class API for this pattern.

TanStack Query is a server-state management library. It handles: caching, background refetching, deduplication of requests, pagination, infinite scroll, optimistic updates, synchronization, and loading/error states — all declaratively.

import { useQuery, useMutation } from '@tanstack/react-query';

function Posts() {
  const { data, isLoading, error } = useQuery({
    queryKey: ['posts'],
    queryFn: () => fetch('/api/posts').then(r => r.json()),
    staleTime: 5 * 60 * 1000, // 5 minutes
  });

  if (isLoading) return <Spinner />;
  if (error) return <Error />;
  return data.map(p => <Post key={p.id} post={p} />);
}

function useNotifications(userId) {
  const [notifications, setNotifications] = useState([]);

  useEffect(() => {
    const ws = new WebSocket(`wss://api.example.com/ws?user=${userId}`);

    ws.onmessage = (event) => {
      const notif = JSON.parse(event.data);
      setNotifications(prev => [notif, ...prev]);
    };

    ws.onerror  = (e) => console.error('WebSocket error', e);
    ws.onclose  = ()  => console.log('WebSocket closed');

    return () => ws.close(); // cleanup on unmount / userId change
  }, [userId]);

  return notifications;
}

Alternatives: SSE (EventSource), long polling, or libraries like Socket.io / Ably.

The <Profiler> component lets you programmatically measure rendering performance in production builds.

import { Profiler } from 'react';

function onRenderCallback(id, phase, actualDuration, baseDuration) {
  sendToAnalytics({ id, phase, actualDuration, baseDuration });
}

<Profiler id="Navigation" onRender={onRenderCallback}>
  <Navigation />
</Profiler>

Parameters: id (label), phase (mount/update), actualDuration (time for this render), baseDuration (estimated without memo), startTime, commitTime.

function Modal({ isOpen, onClose, title, children }) {
  const dialogRef = useRef();

  useEffect(() => {
    if (!isOpen) return;
    dialogRef.current?.focus();
    const onKey = e => { if (e.key === 'Escape') onClose(); };
    document.addEventListener('keydown', onKey);
    return () => document.removeEventListener('keydown', onKey);
  }, [isOpen, onClose]);

  if (!isOpen) return null;

  return createPortal(
    <div role="dialog" aria-modal="true" aria-labelledby="modal-title">
      <div ref={dialogRef} tabIndex={-1}>
        <h2 id="modal-title">{title}</h2>
        {children}
        <button onClick={onClose} aria-label="Close">✕</button>
      </div>
    </div>,
    document.body
  );
}

State normalization stores entity data in a flat map (keyed by ID) rather than nested arrays. This avoids data duplication and makes updates O(1) instead of O(n).

// ❌ Denormalized — hard to update a specific post
{ posts: [{ id: 1, author: { id: 5, name: 'Alice' } }, ...] }

// ✅ Normalized — each entity stored once
{
  posts: { ids: [1], entities: { 1: { id: 1, authorId: 5 } } },
  users: { ids: [5], entities: { 5: { id: 5, name: 'Alice' } } }
}

Redux Toolkit’s createEntityAdapter automates this pattern. TanStack Query handles it automatically via query cache keying.

Key CWV metrics and React-specific fixes:

• LCP (Largest Contentful Paint) — SSR or SSG, preload hero image, eliminate render-blocking resources.
• INP (Interaction to Next Paint) — debounce handlers, use startTransition, avoid long tasks, virtualize large lists.
• CLS (Cumulative Layout Shift) — set explicit dimensions on images/iframes, avoid injecting content above existing content.

// Measure with web-vitals library
import { onINP, onLCP, onCLS } from 'web-vitals';
onINP(metric => sendToAnalytics(metric));
onLCP(metric => sendToAnalytics(metric));

The use Hook (React 19) lets you read the value of a resource — a Promise or a Context — inside render. Unlike other hooks, use can be called inside conditionals and loops.

// Reading a Context with use (equivalent to useContext)
import { use } from 'react';

function Heading({ children }) {
  const level = use(LevelContext);
  return <{`h${level}`}>{children}</{`h${level}`}>;
}

// Reading a Promise (must be wrapped / cache)
function Comments({ commentsPromise }) {
  const comments = use(commentsPromise); // suspends until resolved
  return comments.map(c => <Comment key={c.id} comment={c} />);
}

Key principles for large-scale React apps:

• Feature-based folder structure — group by domain (features/auth, features/dashboard) not by type.
• Clear layer separation — UI components → hooks/services → API layer.
• Strict module boundaries — use barrel exports and enforce with ESLint import rules.
• Micro-frontend or monorepo — NX/Turborepo for team scalability.
• Design system — shared component library (Storybook) consumed by all features.
• Typed contracts — TypeScript + Zod for runtime validation of API responses.
• Testing pyramid — unit (hooks/utils), integration (RTL), e2e (Playwright).

Server Actions let you call server-side functions directly from client components — without manually writing API routes. They’re marked with 'use server' and can be called from form actions or event handlers.

// actions.ts — runs on server
'use server';

export async function createPost(formData: FormData) {
  const title = formData.get('title') as string;
  await db.post.create({ data: { title } });
  revalidatePath('/posts');
}

// Client component
<form action={createPost}>
  <input name="title" />
  <button type="submit">Create</button>
</form>

Streaming SSR uses renderToPipeableStream (Node.js) or renderToReadableStream (Edge) to stream HTML to the browser in chunks rather than waiting for the full page to render.

import { renderToPipeableStream } from 'react-dom/server';

res.setHeader('Content-Type', 'text/html');
const { pipe } = renderToPipeableStream(<App />, {
  onShellReady() { pipe(res); }, // send shell immediately
  onError(err) { console.error(err); }
});

Wrapped in Suspense, slow components don’t block the initial shell. The client progressively hydrates chunks as they stream in. Result: faster FCP + TTFB without sacrificing dynamic content.

Micro-frontends decompose a large frontend into independently deployable apps owned by different teams. Common approaches with React:

• Module Federation (Webpack 5 / Rspack) — dynamically load remote components at runtime.
• iframes — strong isolation, simple, but limited UX/communication.
• Custom Elements / Web Components — wrap React apps as standards-based elements.
• Single-SPA — orchestrates multiple framework apps on one page.

// webpack.config.js (Host) — Module Federation
new ModuleFederationPlugin({
  remotes: {
    cart: 'cart@https://cart.example.com/remoteEntry.js',
  },
})

// In host app
const CartWidget = lazy(() => import('cart/CartWidget'));

React uses a scheduler (the scheduler package) that assigns lanes and priorities to work. Work is queued in a min-heap and processed in priority order using cooperative scheduling (yielding to the browser event loop).

Priority levels (React 18 lanes):

• SyncLane — flushSync, legacy mode. Always processes before paint.
• InputContinuousLane — pointer/scroll events. Processed before next frame.
• DefaultLane — normal setState. Batch and process asap.
• TransitionLane — startTransition. Can be interrupted by higher-priority work.
• OffscreenLane — pre-rendering hidden content.

The scheduler uses MessageChannel to schedule work asynchronously, yielding every ~5ms to let the browser handle input/paint.

React wraps event handlers in batchedUpdates. In React 17 and earlier, this only applied inside React event handlers. In React 18, batching is automatic everywhere via a mechanism called automatic batching.

Internally: each setState call enqueues an update on the fiber’s updateQueue. React defers the re-render by scheduling work asynchronously. Only after the current execution context ends does React flush the queue and process all enqueued updates together in a single render pass.

Calling flushSync forces immediate synchronous flush of the queue.

The React Compiler (previously codenamed “React Forget”) is a Babel plugin developed by the React team that automatically memoizes components, hooks, and JSX expressions at compile time — eliminating the need for manual useMemo, useCallback, and React.memo.

It uses static analysis to identify values whose referential identity needs to be preserved, then inserts the correct memoization. It understands React’s rules of hooks and can prove safety of optimizations.

Released as part of React 19 with Meta running it in production on Instagram.com before public release. Opt in via babel config or Next.js config option.

React’s reconciler (react-reconciler) is decoupled from the host environment. You implement a “host config” that defines how to create, update, and delete nodes in your custom target.

import Reconciler from 'react-reconciler';

const HostConfig = {
  createInstance(type, props) { return { type, props, children: [] }; },
  appendChildToContainer(container, child) { container.children.push(child); },
  commitUpdate(instance, _, __, ___, newProps) { instance.props = newProps; },
  removeChildFromContainer(container, child) { /* ... */ },
  supportsMutation: true,
  // ... ~30 other required methods
};

const MyRenderer = Reconciler.createContainer(HostConfig);

export function render(element, container) {
  MyRenderer.updateContainer(element, container);
}

Examples in the wild: React Three Fiber (WebGL/Three.js), React PDF, React Native, Ink (terminal).

Internally, a Context object has a $$typeof symbol and stores the current value on the provider’s fiber during reconciliation.

When a Provider renders, React pushes the new value onto a context stack (a linked list of fiber nodes). When a useContext consumer renders, React walks up the fiber tree to find the nearest matching Provider and reads its current value.

When the Provider’s value changes, React propagates the change by marking all consumers as needing re-render (a “context propagation bailout” scan). This is O(n) in the subtree size, which is why splitting contexts and memoizing consumers matters for performance.

React.memo uses shallow reference equality. Every render creates new object/array/function references, so memoization is defeated without useMemo/useCallback.

const Child = React.memo(({ style, onClick }) => <div style={style} onClick={onClick}>...</div>);

// ❌ New object on every Parent render — memo is useless
<Child style={{ color: 'red' }} onClick={() => doThing()} />

// ✅ Stable references
const style    = useMemo(() => ({ color: 'red' }), []);
const onClick  = useCallback(() => doThing(), []);
<Child style={style} onClick={onClick} />

Alternative: use the React Compiler which handles this automatically, or design components to accept primitive props.

Race conditions occur when a user triggers multiple requests and the last one resolves before an earlier one, displaying stale data. Solutions:

// Pattern 1: cleanup flag
useEffect(() => {
  let active = true;
  fetchData(id).then(data => { if (active) setData(data); });
  return () => { active = false; };
}, [id]);

// Pattern 2: AbortController
useEffect(() => {
  const controller = new AbortController();
  fetch(url, { signal: controller.signal })
    .then(r => r.json())
    .then(setData)
    .catch(e => { if (e.name !== 'AbortError') setError(e); });
  return () => controller.abort();
}, [url]);

TanStack Query handles race conditions automatically — it cancels in-flight queries when a newer request supersedes them.

// flags.ts
export const flags = {
  newDashboard: Boolean(process.env.NEXT_PUBLIC_FLAG_NEW_DASHBOARD),
};

// Hook
function useFlag(key) {
  const { user } = useAuth();
  const remoteFlags = useQuery({ queryKey: ['flags', user.id], queryFn: fetchFlags });
  return remoteFlags.data?.[key] ?? flags[key] ?? false;
}

// Usage
function App() {
  const showNewDash = useFlag('newDashboard');
  return showNewDash ? <NewDashboard /> : <OldDashboard />;
}

Production systems use services like LaunchDarkly, Statsig, or GrowthBook, which add targeting rules, A/B experimentation, kill switches, and analytics.

// eventBus.ts
type Handler = (data: unknown) => void;
const listeners = new Map<string, Set<Handler>>();

export const eventBus = {
  on(event: string, handler: Handler) {
    if (!listeners.has(event)) listeners.set(event, new Set());
    listeners.get(event)!.add(handler);
    return () => listeners.get(event)!.delete(handler);
  },
  emit(event: string, data?: unknown) {
    listeners.get(event)?.forEach(h => h(data));
  }
};

// Hook
function useEvent<T>(event: string, handler: (data: T) => void) {
  const handlerRef = useRef(handler);
  handlerRef.current = handler;

  useEffect(() => {
    return eventBus.on(event, (data) => handlerRef.current(data as T));
  }, [event]);
}

function useUndoRedo<T>(initial: T) {
  const [history, setHistory] = useState<T[]>([initial]);
  const [index, setIndex]     = useState(0);

  const current = history[index];

  const set = useCallback((newState: T) => {
    const next = history.slice(0, index + 1); // drop future states
    setHistory([...next, newState]);
    setIndex(next.length);
  }, [history, index]);

  const undo = () => setIndex(i => Math.max(0, i - 1));
  const redo = () => setIndex(i => Math.min(history.length - 1, i + 1));

  return { current, set, undo, redo,
    canUndo: index > 0,
    canRedo: index < history.length - 1
  };
}

const STEPS = ['info', 'payment', 'confirm'] as const;

function Wizard() {
  const [searchParams, setSearchParams] = useSearchParams();
  const stepParam = searchParams.get('step');
  const stepIndex = STEPS.indexOf((stepParam ?? 'info') as typeof STEPS[0]);
  const currentStep = STEPS[Math.max(0, stepIndex)];

  const [formData, setFormData] = useState({});

  function goTo(step: typeof STEPS[0]) {
    setSearchParams({ step });
  }

  function saveAndNext(data: object) {
    setFormData(prev => ({ ...prev, ...data }));
    const nextStep = STEPS[stepIndex + 1];
    if (nextStep) goTo(nextStep);
  }

  return (
    <>
      {currentStep === 'info'    && <InfoStep    onNext={saveAndNext} />}
      {currentStep === 'payment' && <PaymentStep onNext={saveAndNext} />}
      {currentStep === 'confirm' && <ConfirmStep data={formData}    />}
    </>
  );
}

Web Workers run JS in a background thread, off the main thread. React UI lives on the main thread, but you can offload CPU-heavy work (image processing, search indexing, AI inference) to a worker and communicate via postMessage.

// worker.ts
self.onmessage = ({ data }) => {
  const result = heavyComputation(data);
  self.postMessage(result);
};

// useWorker.ts
function useWorker(workerPath: string) {
  const workerRef = useRef<Worker>();
  useEffect(() => {
    workerRef.current = new Worker(workerPath, { type: 'module' });
    return () => workerRef.current?.terminate();
  }, [workerPath]);

  const compute = (data: unknown) => new Promise(resolve => {
    workerRef.current!.onmessage = ({ data }) => resolve(data);
    workerRef.current!.postMessage(data);
  });

  return { compute };
}

act() ensures that all state updates, effects, and re-renders are flushed before you make assertions in tests. Without it, tests may assert on stale DOM state.

import { act } from 'react';
import { render } from '@testing-library/react';

test('loads and displays data', async () => {
  await act(async () => {
    render(<DataLoader />);
  });
  // Now state updates + effects have all run
  expect(screen.getByText('Data loaded')).toBeInTheDocument();
});

React Testing Library wraps all its utilities (render, userEvent, fireEvent) in act automatically, which is why you typically don’t need to call it directly.

A production design system typically combines:

• Design tokens — CSS custom properties or JS objects for color, spacing, typography.
• Primitive components — Box, Text, Stack, Grid with token-based props.
• Compound components — Card, Modal, DataTable built from primitives.
• Storybook — living documentation with interactive playground.

// tokens.ts
export const tokens = {
  colors: { primary: '#0066cc', danger: '#dc2626' },
  space: [0, 4, 8, 16, 24, 32, 48, 64],
};

// Button with variant system (using vanilla-extract or Tailwind CVA)
const button = cva('rounded font-medium', {
  variants: {
    intent: {
      primary: 'bg-blue-600 text-white',
      danger:  'bg-red-600 text-white',
      ghost:   'bg-transparent border',
    },
    size: { sm: 'px-2 py-1 text-sm', lg: 'px-6 py-3 text-lg' },
  },
  defaultVariants: { intent: 'primary', size: 'sm' },
});

Key engineering challenges and solutions:

• Conflict resolution — use Operational Transformation (OT) or CRDTs (Yjs, Automerge) to merge concurrent edits without conflicts.
• Sync — WebSocket for real-time updates; CRDT diffs are small and efficient.
• Awareness — broadcast cursor positions and user presence.
• Offline support — CRDTs can merge divergent offline edits on reconnect.
• React integration — bind Yjs doc changes to React state via y-react or custom useSyncExternalStore hook.

import * as Y from 'yjs';
import { WebsocketProvider } from 'y-websocket';

const ydoc = new Y.Doc();
const provider = new WebsocketProvider('wss://y.example.com', 'room-1', ydoc);
const yText = ydoc.getText('content');

// In component:
useSyncExternalStore(
  cb => { yText.observe(cb); return () => yText.unobserve(cb); },
  () => yText.toString()
);

useSyncExternalStore (React 18) is the correct way to subscribe to external (non-React) stores inside components. It ensures consistency under concurrent rendering by providing a snapshot mechanism.

import { useSyncExternalStore } from 'react';

function useWindowWidth() {
  return useSyncExternalStore(
    (callback) => {
      window.addEventListener('resize', callback);
      return () => window.removeEventListener('resize', callback);
    },
    () => window.innerWidth,      // getSnapshot (client)
    () => 1024                   // getServerSnapshot (SSR)
  );
}

Use it when integrating with external state stores (Redux, Zustand, RxJS, browser APIs) to avoid tearing — inconsistent state during concurrent renders.

The Offscreen component (API still stabilizing, called Activity in latest React canary) lets React pre-render trees that are not yet visible, or cache them when they’re hidden — without destroying their state.

<Offscreen mode="hidden">
  <ExpensiveTab />  // rendered but not visible, state preserved
</Offscreen>

Mode options:

• visible — normal rendering
• hidden — rendered off-screen, state preserved, effects paused
• manual — developer controls visibility transitions

Enables: instant tab switching (pre-rendered), keepalive patterns, background rendering. Replaces the display: none hack that destroys React state.

Tearing occurs when React renders a UI snapshot but an external store updates mid-render, causing different components to see different values of the same state — a visually inconsistent UI.

Scenario: Component A reads store version 1 → store updates to version 2 → Component B reads version 2 → they disagree on the same value.

React’s solution: useSyncExternalStore uses a two-phase “getSnapshot” check. After rendering, React verifies that all snapshots are still consistent. If not, it synchronously re-renders — trading some concurrency for consistency.

Libraries using legacy subscription patterns (e.g. old Redux useSelector) are vulnerable to tearing in concurrent mode until they migrate to useSyncExternalStore. RTK Query and modern Zustand handle this correctly.

A production-grade data grid for 100k rows requires multiple techniques in combination:

• Row virtualization — @tanstack/react-virtual or react-window. Only render ~20-50 visible rows.
• Column virtualization — virtual horizontal scrolling for wide tables.
• Memoized row components — React.memo per row with stable props.
• Immutable data structures — structural sharing for efficient diffing.
• Lazy loading — paginated server requests or cursor-based fetching.
• Web Worker offload — filtering, sorting, and aggregation off the main thread.
• Canvas rendering — for extreme performance (AG Grid’s column virtualizer uses canvas for headers).

Production libraries: AG Grid, TanStack Table (headless), react-data-grid.

React 19 ships several transformative features that change how React apps are built:

• React Compiler — automatic memoization; useMemo/useCallback/React.memo become largely unnecessary.
• Server Components (stable) — zero-JS server-rendered components, direct data access, smaller bundles.
• Server Actions (stable) — async server functions callable from clients, simplifying API route boilerplate.
• use() Hook — read Promises and Contexts in render, even inside conditionals.
• useOptimistic — first-class API for optimistic UI updates.
• useFormStatus / useFormState — form state management tied to server actions.
• Asset loading APIs — preload, prefetchDNS, preinit for resource hints directly from components.
• Activity (Offscreen) — keep-alive hidden subtrees with paused effects.

The direction: less client JS, better DX, compiler-driven optimization, and deeper server/client boundary awareness baked into the framework.

Before React 16, the “Stack Reconciler” used synchronous, recursive tree traversal. Once an update started, it could not be interrupted, leading to dropped frames if rendering took longer than 16ms. Fiber is a complete rewrite representing a cooperative scheduling engine. It breaks rendering work into a linked list of mutable “Fiber Nodes.” This allows React to pause rendering, yield control back to the browser to handle user input, and resume or discard the work based on assigned Lane priorities.

import { useState, useTransition, useEffect } from 'react';

export function InventoryDash({ socket }) {
  const [searchTerm, setSearchTerm] = useState('');
  const [inventory, setInventory] = useState([]);
  const [isPending, startTransition] = useTransition();

  // High priority UI update
  const handleSearch = (e) => setSearchTerm(e.target.value);

  useEffect(() => {
    socket.on('stock_update', (data) => {
      // Yielding to Fiber: Process stock updates in the background
      startTransition(() => {
        setInventory(data);
      });
    });
    return () => socket.off('stock_update');
  }, [socket]);

  return (
    <div>
      <input onChange={handleSearch} value={searchTerm} placeholder="Search SKUs..." />
      <List data={inventory} stale={isPending} />
    </div>
  );
}

A generalized algorithm to find the minimum number of operations to transform one tree into another has a complexity of O(n³). For a UI with 1000 nodes, this means one billion comparisons. React implements a heuristic O(n) algorithm based on two assumptions:

1. Two elements of different types will produce different trees. React will tear down the old tree completely and build the new one from scratch.
2. Developers can hint at which child elements remain stable across renders using the key prop.

// BAD: Array index keys break the O(n) diffing heuristic on deletion/sorting
{zones.map((zone, index) => (
  <DeliveryZone key={index} data={zone} /> 
))}

// GOOD: Stable identities enable efficient Fiber reconciliation
{zones.map((zone) => (
  <DeliveryZone key={zone.zoneId} data={zone} />
))}

Double buffering is a technique borrowed from game development to prevent screen tearing. React maintains two Fiber trees: the current tree (reflecting the exact state of the visible DOM) and the workInProgress tree (the draft being calculated in memory).

During the Render phase, all calculations and diffing happen on the workInProgress tree without touching the DOM. Once the Commit phase completes the DOM mutations, React simply swaps the pointers: the workInProgress tree instantly becomes the current tree. If an error or high-priority interruption occurs mid-render, React can safely throw away the workInProgress tree without leaving the user with a broken, half-rendered UI.

Originally, React assigned “expiration times” to updates to determine priority. However, time is linear, making it difficult to express complex concepts like “batch these two background tasks together but preempt them for this specific input.”

React 17+ introduced “Lanes”—a 32-bit bitmask system. Each bit represents a priority level (e.g., SyncLane for inputs, TransitionLane for data fetching). Bitmasks allow the Scheduler to use highly efficient bitwise operations (like & and |) to merge updates, check for overlapping priorities, and decide what task to execute next instantaneously.

When a component’s state or props remain unchanged (verified via shallow equality in React.memo), Fiber “bails out.” It aborts traversing that branch and clones the node directly from the current tree to the workInProgress tree, saving massive CPU cycles.

However, if a Context Provider updates, React scans down the entire tree to find components hooked to that Context. It marks those specific Fiber nodes with a forced update Lane. Even if intermediate parent components trigger a bailout, React will strictly bypass the bailout for the marked Context consumers to ensure they receive the fresh data.

The Render Phase is pure, asynchronous, and interruptible. React calls your component functions, calculates the changes, and flags Fiber nodes with “Effect Tags” (e.g., Placement, Update, Deletion). No DOM mutations happen here.

The Commit Phase is synchronous and uninterruptible. React iterates over the list of Effect Tags and executes the physical DOM mutations (appendChild, removeChild). Afterward, it fires lifecycle hooks like componentDidMount and useLayoutEffect.

useEffect fires asynchronously after the browser has painted the screen. useLayoutEffect fires synchronously before the browser paints. If you mutate the DOM in useEffect, the user will see a visual flicker (the first paint, then the mutation).

import { useLayoutEffect, useRef, useState } from 'react';

export function StarTooltip({ targetRef }) {
  const tooltipRef = useRef(null);
  const [coords, setCoords] = useState({ top: 0, left: 0 });

  useLayoutEffect(() => {
    // Measures and sets coordinates synchronously before paint
    const targetRect = targetRef.current.getBoundingClientRect();
    const tooltipRect = tooltipRef.current.getBoundingClientRect();
    
    setCoords({
      top: targetRect.top - tooltipRect.height,
      left: targetRect.left + (targetRect.width / 2) - (tooltipRect.width / 2)
    });
  }, [targetRef]);

  return <div ref={tooltipRef} style={{ ...coords, position: 'absolute' }}>Chart Data</div>;
}

Browsers consume heavy memory if you attach individual event listeners (like onClick) to thousands of DOM nodes. React solves this by ignoring your inline onClick handlers completely at the DOM level.

Instead, React attaches exactly one event listener per event type to the root container (e.g., div#root). When a user clicks a button, the browser event bubbles to the root. React intercepts it, wraps it in a cross-browser compatible “Synthetic Event,” determines which Fiber node was the target, and simulates the capturing and bubbling phases entirely in memory.

If an error is thrown during the Render phase, React catches it and halts the workInProgress traversal. It then walks up the Fiber tree looking for the nearest node tagged as an Error Boundary (a class component implementing static getDerivedStateFromError).

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

  static getDerivedStateFromError(error) {
    // Halts the crash and schedules a fallback render
    return { hasError: true };
  }

  componentDidCatch(error, info) {
    // Send to Datadog/Sentry
    logToMonitoringService(error, info.componentStack);
  }

  render() {
    if (this.state.hasError) {
      return <div className="fallback">AI Prediction temporarily unavailable.</div>;
    }
    return this.props.children;
  }
}

Deep equality requires recursive traversal of nested objects. If a state object has hundreds of keys, executing a deep comparison on every single keystroke or data tick would O(N) throttle the CPU, destroying performance.

Shallow equality (oldProp === newProp) checks memory references, which is an O(1) instantaneous operation. This is why immutability is an architectural requirement in React. By returning a brand new object reference when mutating state, React instantly knows the data changed without having to inspect the internal keys.

Standard await halts the execution of a JavaScript function entirely until a Promise resolves. In React, halting a render function blocks the thread. use() is designed to integrate with React’s Fiber engine and Suspense. When use() encounters an unresolved Promise, it actually throws that Promise up the component tree. React catches it, suspends the component, renders the nearest Suspense fallback, and resumes rendering only when the Promise resolves.

Crucially, because use() hooks into the compiler rather than standard Hook dispatchers, it can be called conditionally inside if statements and loops, breaking the traditional Rules of Hooks.

import { use, Suspense } from 'react';

function AISummary({ isPremium, summaryPromise }) {
  // Valid in React 19! We can call `use()` inside a conditional block.
  if (!isPremium) {
    return <div>Upgrade to view AI Summary</div>;
  }

  // Throws to Suspense boundary if unresolved, returns data if resolved
  const summary = use(summaryPromise);
  
  return <p>{summary}</p>;
}

“Tearing” occurs when a React application’s UI becomes inconsistent because an external data source (like a Redux store) mutates while React is in the middle of a concurrent Render phase. Because concurrent rendering yields to the main thread, an external event could change the store state. Half the UI might render with the old state, and the bottom half with the new state.

React mitigates this using the useSyncExternalStore hook. It forces React to track the external store’s version during the render. If a mutation is detected mid-render, React immediately discards the torn workInProgress tree and triggers a synchronous, high-priority re-render to guarantee UI consistency.

Server Actions abstract away the API layer. When you mark a function with 'use server', the React compiler extracts it from the client bundle and generates a secure, hidden RPC (Remote Procedure Call) endpoint. When a client component invokes the action, React automatically serializes the arguments, sends a POST request to that endpoint, executes the Node.js logic (like database mutations), and streams the updated UI back to the client.

// action.ts
'use server'
import { db } from '@/lib/db';
import { revalidatePath } from 'next/cache';

export async function updateCartQuantity(formData: FormData) {
  const itemId = formData.get('itemId');
  const qty = parseInt(formData.get('quantity'), 10);
  
  await db.cart.update({ itemId, qty });
  
  // Instructs the server to stream the updated RSC payload to the client
  revalidatePath('/cart'); 
}

// CartItem.tsx (Client or Server Component)
import { updateCartQuantity } from './action';

export function CartItem({ item }) {
  return (
    <form action={updateCartQuantity}>
      <input type="hidden" name="itemId" value={item.id} />
      <input type="number" name="quantity" defaultValue={item.qty} />
      <button type="submit">Update</button>
    </form>
  );
}

With Server Components, the boundary between backend and frontend is porous. It becomes incredibly easy to accidentally pass a raw database object as a prop to a Client Component, which serializes sensitive data (like password hashes or internal API keys) directly into the browser’s HTML payload.

React 19 introduces taintObjectReference. If an architect explicitly “taints” a user object at the database layer, React’s serialization engine will monitor it. If a developer ever accidentally passes that tainted object to a Client Component, the React compiler will aggressively throw a fatal error, preventing the data leak.

Previously, form submissions required boilerplate: e.preventDefault(), setting isSubmitting to true, awaiting a fetch, and handling errors. React 19 native forms integrate directly with the transition API via useActionState (formerly useFormState) and useFormStatus.

import { useFormStatus } from 'react-dom';

// This component can be deeply nested inside the <form>
function SubmitButton() {
  // Automatically reads the pending state of the nearest parent form action
  const { pending } = useFormStatus();

  return (
    <button type="submit" disabled={pending}>
      {pending ? 'Uploading Securely...' : 'Submit Document'}
    </button>
  );
}

Both APIs tell React to deprioritize a render, but they operate on different levels of abstraction.

useTransition is Imperative: You wrap the state setter function (the action). You explicitly tell React, “The state update caused by this specific click/typing event is low priority.”

useDeferredValue is Declarative: You wrap the data value itself. You tell React, “I don’t care where this value came from (props, context, external store), if it changes, keep showing the old value for high-priority renders, and schedule a background render to figure out the new UI.”

Historically, injecting CSS files asynchronously caused a Flash of Unstyled Content (FOUC), and React didn’t know when a stylesheet was fully loaded. React 19 introduces native support for Document Metadata. By rendering <link rel="stylesheet" precedence="default"> inside any component, React hoists the link to the <head>.

Crucially, React will now suspend the Commit phase. It holds the DOM update in memory until the browser confirms the stylesheet is downloaded and parsed, guaranteeing the user never sees unstyled markup.

React requires developers to manually declare dependency arrays in useEffect, useMemo, and useCallback to prevent infinite loops and stale closures. The React Compiler is a build-time Babel plugin that performs static code analysis on your component’s Abstract Syntax Tree (AST).

It understands the data flow and automatically injects low-level memoization caches (using arrays) around values that don’t mutate. Architecturally, this means you can delete almost all useMemo and useCallback hooks from your codebase. The compiler guarantees that a component or calculation will only re-execute if its structural, semantic dependencies genuinely change.

Standard Server-Side Rendering (SSR) requires the browser to download the entire JavaScript bundle before the page becomes interactive (the “Uncanny Valley”). Selective Hydration solves this using <Suspense> boundaries.

React sends the HTML immediately. Instead of waiting for all JS, it hydrates the DOM in chunks. If a user clicks or interacts with a specific Suspense boundary before it is hydrated, React’s event delegation system catches the click, bumps that specific chunk to the highest priority Lane, hydrates it instantly, and replays the user’s click event so no interaction is lost.

Optimistic UI (updating the screen before the server confirms success) usually requires complex rollback logic if the network fails. useOptimistic ties the optimistic state directly to the lifecycle of an ongoing async Action.

import { useOptimistic } from 'react';
import { likePostAction } from './actions';

export function LikeButton({ post }) {
  // optimisticLikes lives only as long as the action is pending
  const [optimisticLikes, addOptimisticLike] = useOptimistic(
    post.likeCount,
    (state, amount) => state + amount
  );

  return (
    <form action={async () => {
      addOptimisticLike(1); // Instantly update UI
      await likePostAction(post.id); // True mutation
    }}>
      <button type="submit">Like ({optimisticLikes})</button>
    </form>
  );
}

Standard SSR sends a finalized, static HTML string to the browser. While great for First Contentful Paint (FCP), it’s a dead end—if you navigate, the server must send a brand new HTML document, destroying client-side state.

The RSC payload is a highly specialized JSON-like stream. It represents the component tree’s Virtual DOM structure, the serialized props fetched from the database, and strict module references (import paths) indicating exactly where Client Component JS chunks should be inserted. React reads this payload on the client and merges it into the existing DOM without destroying client state (like a playing video or an active text input).

Server Components can freely import and render Client Components. However, Client Components cannot import Server Components. If a component with 'use client' imports a Server Component, that Server Component immediately becomes a Client Component, bloats the JS bundle, and causes errors if it uses Node.js modules like `fs`.

To bypass this restriction architecturally, we use the Composition Pattern. The Server Component imports both the Client Component and another Server Component, passing the latter into the former as a children prop.

// Layout.tsx (Server Component)
import { ClientSidebar } from './ClientSidebar';
import { ServerDataFeed } from './ServerDataFeed';

export default function Layout() {
  return (
    // We pass the Server Component through the Client Component's "hole"
    <ClientSidebar>
      <ServerDataFeed /> 
    </ClientSidebar>
  );
}

Because Next.js blends server and client code in the same directory structure, it is incredibly easy to accidentally import a utility function containing database credentials or Node-specific libraries (like `crypto`) into a Client Component. This leaks secrets to the browser and crashes the client bundle.

Architects use “poisoning” to prevent this. By importing the server-only package at the top of sensitive files, you explicitly poison them against client usage. If a developer mistakenly imports that file into a component with a 'use client' directive, the Webpack/Turbopack build instantly fails, preventing catastrophic security breaches.

// lib/db.ts
import 'server-only'; // POISON: Will break the build if leaked to client
import { Pool } from 'pg';

export const db = new Pool({
  connectionString: process.env.DATABASE_URL,
});

Props crossing the network boundary from Server to Client must be strictly serializable. Under the hood, React converts these props into strings inside the RSC payload.

You can pass primitives (strings, numbers, booleans), arrays, Maps, Sets, Dates, and plain objects. You cannot pass class instances (like a custom new User() object), un-serializable APIs (like DOM nodes), or standard functions (event handlers).

Partial Prerendering (PPR) is a groundbreaking optimization that merges Static Site Generation (SSG) and Server-Side Rendering (SSR). Historically, a page was either fast (static) or personalized (dynamic, but slow TTFB).

PPR allows Next.js to statically generate the outer shell of your layout at build time. The dynamic parts are wrapped in <Suspense>. Upon request, the server instantly sends the static shell from a CDN edge node (TTFB near zero). Simultaneously, the server executes the async database calls for the dynamic parts and streams them into the Suspense boundaries over the same HTTP connection.

import { Suspense } from 'react';
import { Skeleton } from '@/components/ui/Skeleton';
import AIPrediction from '@/components/AIPrediction';

export default function HoroscopePage({ params }) {
  return (
    <div className="layout">
      <!-- STATIC SHELL: Cached and served instantly -->
      <h1>Daily Horoscope: {params.sign}</h1>
      <nav>Profile | Settings</nav>
      
      <!-- DYNAMIC STREAM: Resolves and patches the DOM seconds later -->
      <Suspense fallback={<Skeleton message="Consulting the stars..." />}>
        <AIPrediction sign={params.sign} />
      </Suspense>
    </div>
  );
}

The Full Route Cache lives entirely on the server. At build time (or during revalidation), Next.js renders the HTML and RSC payload and stores it on the disk/CDN. Multiple users hitting the same URL are served from this cache.

The Client-Side Router Cache lives entirely in the browser’s memory. When a user navigates between routes, Next.js fetches the RSC payload and stores it locally. If the user clicks “Back” or revisits a previously clicked tab, the UI renders instantly without sending a single network request to the server, preserving a native-app-like feel.

The lifecycle is drastically different from traditional React SPAs:

1. The browser makes an HTTP request. The Node server begins executing the Server Components, making direct database queries.
2. The server generates a specialized RSC payload and a standard HTML string.
3. The HTML string is streamed to the browser to achieve an instant, non-interactive First Paint.
4. The browser receives the RSC payload. React reconciles this payload to construct the Virtual DOM in memory without re-fetching data.
5. Finally, the Client Component JavaScript bundles are downloaded. React “hydrates” the DOM, attaching event listeners to make it interactive.

When a Server Action completes a database mutation, you can invoke revalidatePath('/route') or revalidateTag('cache-tag'). This instructs the Next.js backend to purge its server-side cache for that specific data.

Because the Server Action was initiated from the client, Next.js seamlessly re-runs the Server Components for the current route and streams the updated RSC payload down in the response of the POST request. React diffs this payload and patches the specific DOM elements that changed, completely avoiding a harsh browser refresh.

You cannot initialize React Context inside a Server Component because RSCs run once on the server and do not hold ongoing state. Attempting to use createContext in a server file will throw an error.

To bypass this, you create a dedicated Client Component wrapper (e.g., <ThemeProvider>) that initializes the Context. You then wrap your Server Components (usually in the layout.tsx file) with this provider. The Server Components can fetch initial data and pass it as a serializable prop to the Provider, which then broadcasts the state to all deeply nested Client Components.

Standard SSR (used by older Next.js or Express apps) acts like a bottleneck: it waits for the absolute slowest API call to resolve before sending the <html> string to the browser. If a database query takes 3 seconds, TTFB is 3 seconds.

Streaming SSR utilizes HTTP chunked transfer encoding. Next.js instantly flushes the static layout (headers, navigation) to the browser. As asynchronous Server Components resolve inside <Suspense> boundaries, Next.js streams HTML fragments and tiny inline script tags into the still-open HTTP connection. These scripts instruct the browser to dynamically insert the resolved HTML into the correct placeholder, drastically lowering TTFB and keeping users engaged.

Legacy Redux suffered from massive boilerplate (constants, action creators, reducers spread across files) and the high risk of accidental state mutation. RTK solves this primarily through createSlice, which auto-generates action creators and action types simultaneously.

Architecturally, the biggest shift is RTK’s integration of Immer.js. Immer wraps the state in a JavaScript Proxy. This allows developers to write code that *looks* like mutable state updates (e.g., state.push(item)), but Immer intercepts the mutation and safely produces a perfectly immutable next state under the hood.

import { createSlice } from '@reduxjs/toolkit';

const cartSlice = createSlice({
  name: 'cart',
  initialState: { items: [], total: 0 },
  reducers: {
    // RTK + Immer allows "mutating" logic safely
    updateQuantity(state, action) {
      const item = state.items.find(i => i.id === action.payload.id);
      if (item) {
        item.quantity = action.payload.quantity; // Looks mutable, is actually immutable!
      }
    }
  }
});
export const { updateQuantity } = cartSlice.actions;

React Query and SWR are fantastic standalone libraries for server-state caching. However, an architect chooses RTK Query when the application already heavily relies on Redux for complex client-side state, and that client state needs to tightly couple with the server state.

Because RTK Query generates Redux reducers and middleware automatically, you can listen to RTK Query cache events (like a successful API fetch) inside your standard Redux slices to trigger synchronous client-side UI workflows without bridging two separate state management systems.

// In a standard Redux slice, listening to an RTK Query endpoint:
extraReducers: (builder) => {
  builder.addMatcher(
    api.endpoints.purchaseOrder.matchFulfilled,
    (state, action) => {
      // Synchronously clear the client-side cart when the server purchase succeeds
      state.cartItems = []; 
      state.isCheckoutModalOpen = false;
    }
  );
}

Atomic State (Jotai): State is broken into tiny, independent pieces (“atoms”). A component only subscribes to the specific atoms it needs. It solves the top-down re-render problem of Context because updating one atom only re-renders the components actively listening to it. It is explicit and declarative.

Proxy State (Valtio/MobX): The entire state object is wrapped in a JS Proxy. The proxy intercepts property access (`get`) to automatically track which component reads which property. When a property mutates (`set`), it precisely triggers a re-render only for the components that read that specific property. It is highly implicit and imperative.

Historically, micro-frontends required building separate apps and mashing them together via IFrames or fragile NGINX routing. Module Federation allows multiple independent Webpack builds to share code and dynamically load chunks from each other at runtime over the network.

Architecturally, the most critical configuration is the shared dependencies array. If the “Host App” and “Remote App” both bundle their own copy of `react` and `react-dom`, React will crash with a “multiple instances of React” invariant violation (Hooks will fail). Module Federation negotiates this, ensuring the Host injects its singleton instance of React into the Remote app.

// webpack.config.js (Remote App)
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'checkoutApp',
      filename: 'remoteEntry.js',
      exposes: { './CheckoutWidget': './src/CheckoutWidget' },
      shared: {
        react: { singleton: true, requiredVersion: '^18.2.0' },
        'react-dom': { singleton: true },
      },
    }),
  ],
};

Micro-frontends should ideally be totally decoupled. If Team A’s Cart app crashes, Team B’s Catalog app should still work. Therefore, tightly coupling them to a single monolithic Redux store defeats the purpose.

1. The URL (Best): Pass IDs or search filters via query parameters. It’s universally understood and inherently decoupled.
2. Custom Browser Events: Use the native CustomEvent API. The Catalog dispatches an ‘ADD_TO_CART’ event; the Cart listens globally and updates itself.
3. Shared Zustand/Zustand Store: If heavy state sharing is unavoidable, create a tiny, third micro-frontend that purely exposes a Zustand store via Module Federation, and have both apps subscribe to it.

Zustand solves several developer experience and performance issues inherent to Redux:

• No Context Provider: Redux requires wrapping your app in <Provider store={store}>, tying the store to the React tree. Zustand stores are standard JS modules that live outside the React tree, meaning you can easily read/write state inside non-React files (like an Axios interceptor).
• Transient Updates: Zustand allows you to subscribe to state changes without forcing a React component to re-render, which is crucial for 60FPS animations or scroll-syncing.
• Zero Boilerplate: No actions, no reducers, no dispatching required. Just functions that mutate state.

import { create } from 'zustand';

// Store lives entirely outside the React tree
const useBearStore = create((set) => ({
  bears: 0,
  increasePopulation: () => set((state) => ({ bears: state.bears + 1 })),
  removeAllBears: () => set({ bears: 0 }),
}));

function BearCounter() {
  const bears = useBearStore((state) => state.bears);
  return <h1>{bears} around here ...</h1>;
}

React Context is not a state management tool; it is a dependency injection mechanism. When a Context Provider’s value prop changes, React forces every single component that calls useContext() for that provider to re-render, bypassing React.memo entirely.

In deep, nested JSON responses (e.g., a Post with an array of Comments, each with an Author), updating an author’s profile picture requires finding and mutating every instance of that author buried in the tree. This is incredibly slow and complex.

Normalization flattens the state. It stores entities in an object dictionary keyed by ID ({ id1: {...}, id2: {...} }), and uses arrays of IDs to manage relationships. RTK’s createEntityAdapter provides pre-built reducers (like upsertOne, removeMany) and memoized selectors to instantly manage flat, normalized state tables without writing custom mapping logic.

A common anti-pattern is storing search queries, active tabs, and pagination data in Redux or useState. If a user finds a specific dashboard view and sends the link to a coworker, the coworker will see the default layout because the state was trapped in the sender’s local browser memory.

Architects promote the URL (Search Params) to be the Single Source of Truth for navigational state. The React component reads useSearchParams() to render the UI, and to update state, it pushes a new route via the history API. This guarantees that any complex UI view is 100% shareable, reproducible, and indexable by search engines.

Historically, Redux used Thunks (too simple for complex flows) or Sagas (complex Generator function syntax). RTK introduced Listener Middleware, a lightweight alternative to Sagas. It allows you to run imperative, asynchronous logic in response to specific dispatched actions.

If an API call fails due to an expired token, the Listener catches the specific “rejected” action, pauses all other outbound queries, dispatches a token refresh API call, and upon success, re-dispatches the original failed queries.

import { createListenerMiddleware } from '@reduxjs/toolkit';

const listenerMiddleware = createListenerMiddleware();

listenerMiddleware.startListening({
  matcher: api.endpoints.getUser.matchRejected,
  effect: async (action, listenerApi) => {
    if (action.payload.status === 401) {
      // Pause further processing, trigger refresh token
      const success = await listenerApi.dispatch(refreshTokenRoute());
      if (success) {
        // Retry original action
        listenerApi.dispatch(api.endpoints.getUser.initiate()); 
      }
    }
  }
});

An architect approaches memory leaks systematically using the Chrome DevTools “Memory” tab. The core technique is the 3-Snapshot Method. You take Snapshot 1 at baseline. You perform the suspected action (e.g., opening and closing a complex data grid component). You take Snapshot 2. You repeat the action and take Snapshot 3.

You then filter Snapshot 3 for objects allocated between Snapshots 1 and 2. Specifically, you search for “Detached DOM elements” or instances of your React components (like `DataGrid`). If the component is unmounted from the UI but still exists in the heap snapshot, you have successfully identified a leak.

Memory leaks in React rarely originate from the virtual DOM itself; they almost exclusively stem from poorly managed closure scopes inside useEffect or external event subscriptions. When a component registers an interval or listener, the callback function forms a closure over the component’s lexical scope.

If the component unmounts but the listener isn’t cleanly removed, the JavaScript engine’s Garbage Collector (GC) cannot free the memory. The browser’s native API still holds a reference to that callback—and by extension, the entire component state captured in the closure.

import { useEffect, useRef, useState } from 'react';

export function DeliveryCountdown({ orderId }) {
  const [timeLeft, setTimeLeft] = useState(1800);
  const timerRef = useRef(null);

  useEffect(() => {
    // Architect tip: Store the interval ID in a ref to guarantee clearing 
    // even if the component re-renders rapidly before unmounting.
    timerRef.current = setInterval(() => {
      setTimeLeft((prev) => (prev <= 1 ? 0 : prev - 1));
    }, 1000);

    // CRITICAL: The cleanup function that prevents the memory leak
    return () => clearInterval(timerRef.current);
  }, [orderId]);

  return <div>{Math.floor(timeLeft / 60)} mins remaining</div>;
}

When analyzing a Heap Snapshot, understanding these two columns is critical for pinpointing the root cause of a leak.

Shallow Size: The memory allocated for the object itself. For a React component, this is usually tiny—just the memory required to hold the primitive values and the memory pointers to its children.

Retained Size: The massive amount of memory that would be freed if that specific object, and all the dependent objects it points to, were deleted. If a tiny 50-byte event listener closure holds a reference to a 50MB Redux data array, its shallow size is 50 bytes, but its retained size is 50MB.

The React Profiler records how long components take to render. It splits this into two metrics to help you judge the effectiveness of your memoization (React.memo, useMemo).

Actual Duration: The literal time spent rendering the component and its children for the current specific update. If children bailed out due to memoization, this number will be low.

Base Duration: The estimated time it would take to completely render the component tree from scratch (like on initial mount) without any memoization or bailout optimizations. If your Actual Duration is consistently near your Base Duration during updates, your memoization strategy is failing.

Relying purely on React DevTools locally doesn’t tell you how your app performs on a low-end Android phone in production. React outputs marks using the native browser User Timing API. Architects instantiate a PerformanceObserver to listen for specific “mark” and “measure” events programmatically.

// Tracking React rendering bottlenecks in production
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // React tags its internal performance marks with an emoji or specific prefix
    if (entry.name.includes('⚛️')) {
      console.log(`React Phase: ${entry.name} took ${entry.duration}ms`);
      // sendToAnalytics(entry.name, entry.duration);
    }
  }
});

// Observe custom marks and measures
observer.observe({ entryTypes: ['mark', 'measure'] });

Developers often create overly nested component trees (e.g., wrapping every element in multiple HOCs or context providers). Even if these components are purely presentational and execute quickly, a massive tree has severe hidden costs.

React must allocate a Fiber node object for every single component. A tree with 10,000 nodes means 10,000 objects in the V8 JS heap. During reconciliation, React must recursively traverse this massive linked list. This creates constant CPU overhead, inflates the Javascript memory heap, and triggers aggressive Garbage Collection (GC). GC events are “Stop-The-World”—they freeze the main thread, causing severe scrolling stutters on mobile devices.

Mobile CPUs severely struggle to decompress and parse massive JavaScript bundles. If you ship a 5MB JS bundle, a modern iPhone parses it in 200ms, but a low-end Android device might take 3-4 seconds, paralyzing the UI.

Architectural optimizations require aggressive Route-level code splitting (via React.lazy or Next.js dynamic imports). You must avoid “Barrel Files” (export * from './components') which trick Webpack into bundling the entire component library when only a single button is needed. Finally, migrating heavy dependencies (like Markdown parsers or Date formatters) to React Server Components (RSCs) physically removes them from the mobile device’s parse queue.

V8 compiles JavaScript down to ultra-fast machine code by making assumptions about object shapes (Hidden Classes). If a function always receives an object with { x: number, y: number }, V8 optimizes it. This is called a “Monomorphic” function.

If a React component dynamically deletes keys from its state (delete state.userId) instead of setting them to null, it changes the physical shape of the object. V8 detects this, throws away the optimized machine code, and falls back to slow, interpreted execution (a “Deopt”). To keep React fast, architects mandate that state object shapes must remain completely uniform throughout their lifecycle.

// BAD: Changes object shape, forces V8 engine de-optimization
const handleLogout = () => {
  const newState = { ...user };
  delete newState.token; 
  setUser(newState);
};

// GOOD: Preserves object shape, keeps V8 execution lightning fast
const handleLogout = () => {
  setUser(prev => ({ ...prev, token: null }));
};

The naive approach to code splitting is lazily loading heavy components right when they render. This results in the user clicking a button, waiting for a network request, and staring at a blank screen or a jerky layout shift.

Layout Thrashing (or Forced Synchronous Layout) happens when you repeatedly alternate between reading DOM measurements (like element.offsetHeight) and writing DOM mutations (like element.style.height = '100px') in a loop or across uncoordinated components.

When you read a measurement, the browser assumes the layout is clean. If you write a mutation, the layout is dirtied. If you read again immediately, the browser is forced to halt JS execution and synchronously recalculate the entire page layout to give you the correct measurement. Architects prevent this by enforcing strict separation: batch all read operations first, store the values, and execute all write operations afterward (often utilizing libraries like fastdom to orchestrate this).

React is fundamentally broken into two distinct parts: the Reconciler (which handles the Fiber engine, state updates, diffing, and component lifecycles) and the Renderer (which applies those updates to a specific environment, like the DOM or Native iOS).

The react-reconciler is an NPM package that exposes the core Fiber engine. To build a custom renderer, an architect feeds a HostConfig object into this reconciler. The reconciler handles all the complex state management, and whenever the Virtual DOM changes, it calls your HostConfig methods to mutate your specific environment.

import ReactReconciler from 'react-reconciler';

// The "translation layer" between React and your custom environment
const HostConfig = {
  createInstance(type, props) {
    if (type === 'text') return new TerminalTextNode(props.children);
    if (type === 'box') return new TerminalBoxNode(props);
  },
  appendInitialChild(parent, child) {
    parent.appendChild(child);
  },
  // ... dozens of other required mutation methods
};

const CustomRenderer = ReactReconciler(HostConfig);
CustomRenderer.render(<App />, terminalRootContainer);

Unlike react-dom, which knows that <div> maps to document.createElement('div'), a custom renderer must maintain a dictionary or factory mapping string types to specific target classes.

In React Three Fiber (R3F), when you write <mesh />, the HostConfig.createInstance method catches the string “mesh”. It does not create an HTML tag; instead, it instantiates a new THREE.Mesh() object. When React updates a prop like position={[1, 2, 3]}, the renderer intercepts this and executes threeObject.position.set(1, 2, 3).

The HostConfig is the contract between React’s pure JavaScript logic and the target host environment. It forces the developer to provide concrete implementations for Abstract UI concepts.

It contains lifecycle hooks that map directly to the Commit Phase. For example: createInstance (called when a new element is mounted), commitUpdate (called when props change), removeChild (called on unmount), and createTextInstance. By implementing these specific methods, you teach React how to draw, update, and erase things in an environment it natively knows nothing about.

In the legacy architecture, the JavaScript thread (running Hermes/JSC) and the Native UI thread (Java/Objective-C) were completely isolated. They could only communicate by passing messages over an asynchronous “Bridge”.

Every time React Native wanted to update a ``, it had to serialize the command into a massive JSON string, send it over the bridge, and wait for the native side to deserialize and execute it. Because this was asynchronous and batched, high-frequency events (like scrolling a list at 60 FPS or tracking a drag gesture) flooded the bridge, causing massive layout thrashing, dropped frames, and “white flashes” of unrendered UI.

Fabric represents the total architectural rewrite of React Native. It completely eliminates the asynchronous JSON Bridge. Instead, it utilizes JSI (JavaScript Interface).

JSI allows C++ to expose native UI objects directly to the JavaScript engine’s memory space. JavaScript can now hold direct references to C++ Host Objects and call their methods synchronously. This allows React to mutate Native UI components exactly like it mutates the DOM in a browser—instantly and precisely—enabling flawlessly smooth 120 FPS animations without serialization overhead.

React’s Synthetic Event system (onClick, onChange) does not exist in react-reconciler; it is bundled exclusively within react-dom. If you build a custom renderer for HTML5 Canvas, a `` does absolutely nothing natively because the Canvas is just one giant bitmap pixel array.

Architects must build a custom event delegation system. You attach native DOM mouse listeners to the global Canvas element. On click, you calculate the X/Y coordinates. You then use an algorithm (like Raycasting for 3D/WebGL, or geometric hit-testing for 2D) to figure out which of your React-managed instances intersects with those coordinates. Finally, you manually invoke the `onClick` prop stored on that instance.

React does not attach event listeners to individual DOM nodes to save memory. Instead, it uses Event Delegation. Prior to React 17, React attached a single event listener for every event type (click, keypress) directly to the global document object.

The React 17 Architectural Shift: React changed delegation from the document to the specific React Root Container (the div#root you pass to createRoot). This was a massive change for Micro-frontends. Previously, if you embedded a React 16 app inside a React 15 app on the same page, their document-level event listeners would clobber each other. Moving delegation to the root container safely isolates multiple React applications living on the exact same DOM tree.

The Commit Phase is broken into three distinct sub-phases: Before Mutation, Mutation, and Layout.

During the Mutation Phase, React physically alters the DOM. It iterates over the Fiber nodes flagged with “Effect Tags” (calculated during the Render phase). It executes appendChild, removeChild, and updates className or style attributes. Crucially, this is also the exact moment React detaches old ref values and attaches new ref instances to the newly mutated DOM nodes.

Native DOM form events are highly fragmented across browsers (e.g., IE/Edge handling input differently than Safari). A native onInput event fires at different times than an onChange event depending on the OS.

React abstracts this chaos. When you use onChange in React, it isn’t simply binding to the native onChange. React’s internal event plugins monitor a combination of native events—input, keydown, keyup, paste, and proprietary browser events. It normalizes this data into a single, predictable SyntheticEvent, guaranteeing that an architect’s form logic behaves identically across all devices and browsers.

Yes. Fundamentally, React is not a UI library; it is an optimized state-machine engine that diffs trees over time. Any system that can be represented as a hierarchical tree of state can be managed by React.

import { render } from 'react-hardware';

function BlinkingLED({ isBlinking }) {
  // Instead of DOM nodes, this renderer maps to physical GPIO pins
  return (
    <pin pin={13} mode="OUTPUT" value={isBlinking ? 'HIGH' : 'LOW'} />
  );
}

// Renders the state tree directly to the serial port connected to the Arduino
render(<BlinkingLED isBlinking={true} />, '/dev/tty.usbmodem1411');

When building highly reusable components (like a Select Dropdown for a UI library), hardcoding every possible edge case via boolean props (e.g., closeOnSelect={false}) bloats the component.

The State Reducer pattern solves this by giving the component’s consumer direct access to intercept state transitions. The component manages its own state via an internal useReducer, but accepts a stateReducer prop. Before applying any state change, the component passes the proposed change to the consumer’s reducer, allowing the consumer to modify or completely cancel the update.

// Inside the reusable library component
function useSelect(stateReducer = (state, action) => action.changes) {
  const [state, dispatch] = useReducer((state, action) => {
    const changes = internalReducer(state, action);
    // Inversion of Control: Let the user override our internal logic
    return stateReducer(state, { ...action, changes }); 
  }, initialState);
  // ...
}

While Context is commonly used for global Dependency Injection (DI), it forces the component to be deeply coupled to the React tree, making isolated Unit Testing difficult. True DI in React is achieved via Component Injection (Render Props) or passing service interfaces directly as props.

By passing the service/component as a prop, the component becomes a pure orchestrator. It knows what to execute, but relies on the parent to define how it executes.

// Generic Dashboard component receives its dependencies as props
export function Dashboard({ LoggerService, AnalyticsAdapter, ChartComponent }) {
  const handleLoad = () => {
    LoggerService.info('Dashboard mounted');
    AnalyticsAdapter.trackEvent('view_dashboard');
  };

  return (
    <div onLoad={handleLoad}>
      <!-- We don't care if this is a D3 Chart or a Chart.js Chart -->
      <ChartComponent data={data} /> 
    </div>
  );
}

Standard state management stores the current state. Event Sourcing never mutates a state object; instead, it stores an append-only array of immutable events (e.g., [{ type: 'ADD_ITEM', id: 1 }, { type: 'CHANGE_QTY', id: 1, qty: 5 }]). The current UI state is derived on the fly by reducing (replaying) these events from the beginning.

Headless UI components provide zero markup and zero CSS. They exclusively encapsulate complex logic, state machinery, and W3C accessibility (ARIA) attributes. They expose this logic via custom hooks or the Render Props pattern.

The consumer uses the hook, receives an object of event handlers and ARIA attributes (like aria-expanded or onKeyDown), and manually spreads (...) them onto their own styled HTML elements, completely decoupling the brains from the beauty.

// The Headless Hook (Library Code)
export function useAccordion() {
  const [isOpen, setIsOpen] = useState(false);
  return {
    isOpen,
    triggerProps: {
      onClick: () => setIsOpen(!isOpen),
      'aria-expanded': isOpen,
      'aria-controls': 'accordion-content',
    },
    contentProps: {
      id: 'accordion-content',
      hidden: !isOpen,
    }
  };
}

// The Consumer (App Code)
function MyStyledAccordion() {
  const { triggerProps, contentProps } = useAccordion();
  return (
    <div className="tailwind-wrapper">
      <button className="bg-blue-500" {...triggerProps}>Toggle</button>
      <div className="p-4" {...contentProps}>Content inside</div>
    </div>
  );
}

Architects forbid hardcoding z-index: 9999. Z-indexes only work within their local Stacking Context (created by position: relative or transform). If a parent has z-index: 1, a child modal with z-index: 99999 will still be trapped underneath an adjacent sibling with z-index: 2.

The architectural solution is React Portals. You create a sibling <div id="portal-root"> at the absolute bottom of your <body>, completely outside your React app root. Whenever a Component needs to break out (Modals, Tooltips, Toasts), you use ReactDOM.createPortal(child, domNode). The logic stays in your component tree, but the physical HTML is injected at the end of the document, naturally rendering on top of everything without fighting Z-index wars.

Traditional state machines (like `useReducer`) are passive; they only calculate the next state when an event is dispatched. They cannot easily manage asynchronous side effects or time.

The Actor Model allows you to spawn independent “Actors” that run concurrently. An Actor maintains its own state and can send and receive asynchronous messages. If you build a complex flow using XState, the state machine itself can trigger an API call, wait for the response, transition to an ‘error’ state, and send a message back to the React component, completely decoupling orchestration logic from the view.

Heavy libraries (like react-beautiful-dnd) often bloat bundles. For many use cases, the native HTML5 Drag and Drop API is sufficient when orchestrated correctly with React state.

You apply the draggable={true} attribute to the source element. In onDragStart, you store the dragged item’s ID in React state. On the target container, you must call e.preventDefault() inside the onDragOver event; otherwise, the browser forbids dropping. Finally, in the target’s onDrop event, you read the dragged ID from state and trigger your reducer/state mutation to move the item.

If you build an Excel-like data grid with 1,000 cells and apply tabindex="0" to all of them, a user relying on a keyboard will have to press “Tab” 1,000 times to move past the table. This is an accessibility violation.

Wizards that rely on const [step, setStep] = useState(1) break immediately if the user accidentally hits the browser’s “Back” button (it navigates them completely away from the app instead of back one step). It also makes deep linking impossible.

Architects treat Wizards as Nested Routes or URL Search Parameters (e.g., /onboarding?step=profile). The central state (the accumulated form data) is held in a higher-order Context or Zustand store. The routing library handles the “Next” and “Back” branch logic by pushing new URL parameters, perfectly aligning the browser history with the Wizard steps.

Isomorphic (or Universal) components execute the exact same JavaScript code on the Node.js server to generate the initial HTML, and then again in the browser to hydrate the DOM.

The danger is Hydration Mismatches. If an isomorphic component renders new Date().getTime(), the Node server evaluates the time at 12:00 PM. The browser downloads the JS and evaluates the time at 12:01 PM. Because the browser’s virtual DOM (12:01) does not match the server’s HTML (12:00), React throws a hydration error and forces a costly synchronous re-render of the entire tree. Architects bypass this using useEffect (which only runs on the client) to set dynamic client-specific data after the initial consistent render.

Most React Unit tests run in JSDOM (via Jest or Vitest). JSDOM is a headless JavaScript implementation of the DOM, but it completely lacks a rendering engine. Therefore, layout APIs like `IntersectionObserver` and animation APIs like `requestAnimationFrame` literally do not exist or silently fail.

Architects solve this in two ways. The first is to mock the global API in the test setup file, manually triggering the observer callbacks to simulate scrolling. The better architectural shift is to move away from JSDOM entirely for visual components and use Cypress Component Testing or Playwright Component Testing, which mounts the isolated React component inside a real Chrome/Webkit browser engine, executing native layout APIs flawlessly.

// Vitest/Jest setup: Mocking IntersectionObserver for JSDOM
class MockIntersectionObserver {
  constructor(callback) {
    this.callback = callback;
  }
  observe(element) {
    // Manually trigger the callback to simulate an element entering the viewport
    this.callback([{ isIntersecting: true, target: element }]);
  }
  unobserve() {}
  disconnect() {}
}
global.IntersectionObserver = MockIntersectionObserver;

Visual Regression Testing (via tools like Percy or Chromatic) renders your components in a headless browser, takes screenshots, and compares them pixel-by-pixel against a baseline image from the `main` branch. If a CSS change shifts a button 2 pixels, the test fails.

The main pitfall is brittleness and false negatives. Dynamic data (like rendering `new Date()`), slight OS font anti-aliasing differences (Mac vs. Linux CI servers), and CSS animations cause tests to fail constantly even when the UI is correct. Architects mitigate this by mocking all dates/times globally, forcing a specific random seed, and disabling all CSS animations (`* { animation: none !important; }`) injected during the test run.

You cannot test a component that connects to `ws://localhost:8080` in CI without spinning up a real backend server, which makes tests slow and flaky. You must intercept the native `WebSocket` object directly in the testing environment.

React Testing Library (RTL) traditionally mounts components in the browser (JSDOM). Because React Server Components execute strictly in Node.js and often contain raw database queries, rendering them in JSDOM fails instantly.

The Strategy: Do not try to unit test the rendering of an RSC. Instead, test the architecture in three layers:

1. Unit Test: Extract the data-fetching logic and Server Actions into isolated pure functions and test them using standard Node/Vitest test runners.
2. Component Test: Extract the interactive UI into Client Components and test them using RTL/JSDOM.
3. E2E Test: Use Playwright to visit the actual route. This tests the integration—that the Server Component successfully passed the RSC payload to the Client Component.

If your application heavily uses `React.lazy` or Next.js `dynamic`, standard synchronous test runners will unmount the component before the lazy chunk finishes downloading. As a result, Istanbul (the coverage tool) reports 0% coverage on those dynamically imported files, even if they work perfectly.

Architects fix this by wrapping the render call in an asynchronous `act()` block and explicitly awaiting the resolution of the Suspense boundary using `findByText` or `findByTestId`. This forces the JSDOM event loop to wait for the mocked chunk to resolve, ensuring the execution path runs and coverage is accurately recorded.

Traditional coverage only tells you if a line of code was executed, not if the test is actually meaningful. A test without an `expect` assertion provides 100% coverage but catches zero bugs.

Mutation Testing (using tools like Stryker) tests the quality of your test suite. It automatically alters your source code (e.g., changing `amount > 10` to `amount < 10` or swapping `+` for `-`) and runs your test suite. If your tests pass despite the broken code, the mutation "survived," exposing a weak or missing assertion. If the test fails, the mutation was "killed," proving the test is robust.

Unlike REST APIs, where every endpoint has a unique URL (`/api/users`, `/api/orders`), GraphQL routes all traffic through a single POST endpoint (`/graphql`). You cannot simply mock the URL; you must intercept the network request, parse the JSON body, read the `operationName`, and return conditional mock data.

// Playwright GraphQL Mocking
await page.route('**/graphql', async (route) => {
  const request = route.request();
  const postData = JSON.parse(request.postData());

  if (postData.operationName === 'GetProfile') {
    // Intercept and return fake profile data
    await route.fulfill({
      status: 200,
      contentType: 'application/json',
      body: JSON.stringify({ data: { user: { name: 'Admin', role: 'architect' } } })
    });
  } else {
    // Let other queries (like analytics) pass through to the real server
    await route.continue();
  }
});

Manual heap snapshots are great for debugging, but memory leaks will continually regress without automated enforcement. Architects use Playwright connected to Chrome via the CDP (Chrome DevTools Protocol) to automate leak detection in CI.

Manual accessibility audits are slow. Architects enforce baseline a11y compliance by integrating the `jest-axe` library directly into the React Testing Library suite.

During a unit test, you render the component to the JSDOM, pass the resulting HTML container into the `axe()` function, and assert `toHaveNoViolations()`. This instantly catches missing `aria-labels`, invalid ARIA roles, duplicated IDs, and contrast issues before the code is ever merged.

import { render } from '@testing-library/react';
import { axe, toHaveNoViolations } from 'jest-axe';
expect.extend(toHaveNoViolations);

it('should have no accessibility violations', async () => {
  const { container } = render(<ComplexDataGrid data={mockData} />);
  
  // Scans the DOM output against WCAG standards
  const results = await axe(container);
  
  expect(results).toHaveNoViolations();
});

E2E tests in Playwright or Cypress become “flaky” (randomly failing) due to asynchronous unpredictability: network latency, CSS animation delays, or slow React hydration. Architects enforce strict rules to eradicate flakiness:

• Never use hardcoded sleeps: Avoid `await page.waitForTimeout(2000)`. Always wait for explicit visual states, like `await expect(locator).toBeVisible()`.
• Mock third-party scripts: Block requests to Google Analytics, Intercom, or ad networks that mutate the DOM unexpectedly and slow down the page.
• Wait for Hydration: React might render the HTML, but clicks fail if JS hasn’t hydrated. Expose a global `window.__REACT_HYDRATED__ = true` flag on mount, and have the E2E test wait for this flag before interacting.

Webpack is a Bundler. When you start the dev server, it crawls your entire application tree, compiles every module, resolves dependencies, and packs them into a single massive JS file in memory before the browser can render anything. As the app grows, boot time crawls to a halt.

Vite utilizes Native ESM (ECMAScript Modules). It does not bundle the code during development. It serves your source code directly to the browser over HTTP as individual native ES modules. When the browser requests a specific file, Vite compiles only that file on demand using esbuild (written in Rust/Go). This makes local boot times near-instantaneous, regardless of the application’s overall size.

Tree Shaking (Dead Code Elimination) relies exclusively on static ES6 module syntax (import and export). During the build, the bundler statically analyzes the AST (Abstract Syntax Tree) to trace exactly which exports are used. Unused exports are stripped from the final bundle.

Libraries fail to tree-shake for two reasons: First, if they are compiled to CommonJS (require), which is dynamic and cannot be statically analyzed. Second, due to Side Effects. If a library file mutates a global object (e.g., window.MyPolyfill = true) just by being imported, the bundler cannot safely delete that file even if no functions from it are explicitly called. Architects fix this by enforcing the "sideEffects": false flag in the library’s package.json.

Shipping a monolithic 5MB `main.js` kills Time to Interactive (TTI). Architects implement strict chunking boundaries to maximize browser caching.

export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        manualChunks: (id) => {
          if (id.includes('node_modules')) {
            if (id.includes('react') || id.includes('react-dom')) {
              return 'vendor-react'; // Framework chunk
            }
            return 'vendor'; // Other libraries
          }
        }
      }
    }
  }
});

AST (Abstract Syntax Tree) tools intercept source code and rewrite it before the browser sees it. For React, this means compiling JSX into React.createElement or stripping out TypeScript types.

Historically, Babel (written in JavaScript) handled this. However, Babel is single-threaded and bound by JS execution speeds. Architects are moving to SWC (Speedy Web Compiler) because it is written in Rust. It executes natively on multi-core CPUs, transforming massive React codebases up to 20x faster than Babel, radically reducing CI/CD pipeline deployment times.

An offline-first architecture intercepts all network requests before they leave the browser using a Service Worker (usually generated via Google Workbox in the Webpack/Vite config).

The Service Worker applies specific caching strategies. For static React assets (JS/CSS chunks), it uses Cache First (serving files from the local disk instantly). For critical API data, it uses Network First, falling back to Cache. If the user loses connection on the subway, the API fetch fails, but the Service Worker intercepts the failure and returns the last known JSON payload from the Cache Storage API, allowing the React UI to remain fully functional.

Traditional HMR injected new JavaScript into the browser but often destroyed React component state because it couldn’t map the new code to the existing Virtual DOM nodes. You would save a file, and your filled-out form would suddenly blank out.

React Fast Refresh fixes this. It is deeply integrated with the React Reconciler. When a component file changes, the bundler sends the new function over a WebSocket. Fast Refresh instructs React to re-render that specific component subtree. Crucially, it matches the hook signatures; if the useState order hasn’t changed, React seamlessly maps the old state to the newly injected component logic without losing the user’s data.

WebAssembly is a binary instruction format that runs in the browser at near-native C++ speeds. JavaScript is heavily bottlenecked by garbage collection and JIT compilation during intense math operations.

import { useEffect, useState } from 'react';

export function WasmFilter() {
  const [wasmModule, setWasmModule] = useState(null);

  useEffect(() => {
    // Asynchronously instantiate the WebAssembly binary
    WebAssembly.instantiateStreaming(fetch('/imageProcessor.wasm'))
      .then(obj => setWasmModule(obj.instance.exports));
  }, []);

  const applyFilter = (imageData) => {
    if (!wasmModule) return;
    // Execute C++ logic directly from React
    wasmModule.applyBlur(imageData, imageData.length);
  };

  return <button onClick={applyFilter}>Apply Heavy Filter</button>;
}

Architects regularly run webpack-bundle-analyzer (or rollup-plugin-visualizer). A common massive issue is seeing two different versions of the same library (e.g., `lodash@4.1` and `lodash@4.17`) packed into the final build because two different third-party React components depend on strictly different versions.

To fix this and force a singleton instance, architects use the resolutions field in package.json (for Yarn) or overrides (for NPM). This forcibly overrides the dependency tree, instructing the bundler to resolve all requests for that library to one single, canonical version, stripping megabytes of duplicated code from the chunk.

When using `React.lazy`, the browser won’t even start downloading the chunk until the component is actually required to render, which causes a loading spinner.

Architects use Webpack Magic Comments to control browser priority heuristics. Adding /* webpackPrefetch: true */ to a dynamic import instructs Webpack to inject a <link rel="prefetch"> tag. The browser will silently download the chunk in the background only when it is completely idle. /* webpackPreload: true */ instructs the browser to download it immediately in parallel with the main bundle, reserving it for chunks required milliseconds after the initial load.

// Triggers a background download during browser idle time
const HeavyDashboard = React.lazy(() => import(
  /* webpackPrefetch: true */
  /* webpackChunkName: "dashboard-view" */
  './HeavyDashboard'
));

React executes in the user’s browser, which is a fundamentally insecure environment. Any environment variable accessed via process.env.API_KEY on the client is string-replaced during the build process and is fully visible to anyone who inspects the compiled JS file.

Architects enforce a strict prefixing strategy (like NEXT_PUBLIC_ in Next.js or VITE_ in Vite). The bundler is configured to only inject variables with this prefix into the client build. True secrets (database passwords, private API keys) are never prefixed, ensuring the bundler completely ignores them, keeping them safely confined to the secure Node.js server executing the Server Components or API routes.

React automatically escapes text strings to prevent XSS. However, if you are building a CMS or Markdown parser, you must inject raw HTML using dangerouslySetInnerHTML. This bypasses React’s security, allowing attackers to inject <script> tags or <img onerror="stealToken()"> payloads.

Architects mitigate this by strictly enforcing a Sanitization layer (like DOMPurify). DOMPurify parses the dirty HTML string, builds a DOM tree in memory, and violently strips out any tags, attributes, or event handlers that are not explicitly whitelisted before passing it to React.

import DOMPurify from 'dompurify';

export function MarkdownRenderer({ dirtyHtml }) {
  // Never pass raw user input directly to React
  const cleanHtml = DOMPurify.sanitize(dirtyHtml, {
    ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a', 'p', 'h1'],
    ALLOWED_ATTR: ['href'] // Only allow safe attributes
  });

  return <div dangerouslySetInnerHTML={{ __html: cleanHtml }} />;
}

Storing a JWT in localStorage makes it incredibly easy for the React app to read the token and attach it to API headers. However, if a single XSS vulnerability exists anywhere in your app (or a third-party dependency), malicious JS can instantly read localStorage and steal the token.

HttpOnly Cookies solve this because the browser explicitly prevents JavaScript from reading the cookie. However, cookies automatically attach to every request, opening the app to CSRF (Cross-Site Request Forgery). An attacker can trick the user into clicking a link, and the browser will blindly attach the authentication cookie to the forged request. Architects solve this by using HttpOnly cookies paired with strict SameSite=Strict attributes and anti-CSRF header tokens.

A strict CSP prevents XSS by forbidding the browser from executing inline scripts (<script>alert(1)</script>) or inline styles.

React Server Components and SSR frameworks (like Next.js) often inject inline scripts to pass the hydration payload or manage styling (e.g., Styled Components). To comply with CSP, an architect must configure the server to generate a cryptographically secure random Nonce on every request. This nonce must be attached to the CSP HTTP header, and then passed into the React application so React can attach `nonce=”random_value”` to the inline script/style tags it generates.

DOM Clobbering is a legacy browser quirk where HTML elements with an id or name attribute are automatically mapped to properties on the global window object.

If a modal opens and a user presses “Tab”, the focus will eventually leave the modal and highlight elements in the background UI. This is highly disorienting for screen readers and technically allows interaction with an “inactive” background state.

Architects implement a Focus Trap. You listen to the `keydown` event on the modal. If the user presses “Tab” while focused on the last focusable element in the modal, you execute `e.preventDefault()` and programmatically call `.focus()` on the first element in the modal, creating an infinite loop. Crucially, when the modal closes, you must restore focus to the exact button that originally opened the modal.

In a traditional website, clicking “Submit” reloads the page, and the screen reader reads the new page title (“Success!”). In a React SPA, clicking submit might just render a tiny green checkmark dynamically. A blind user will hear absolutely nothing and assume the form is broken.

Architects use aria-live regions. You place an invisible <div aria-live="polite" aria-atomic="true"> permanently in the DOM. When the React async action succeeds, you update the text inside this div. The browser detects the DOM mutation and instructs the screen reader to interrupt its flow and audibly announce the new text (“Form submitted successfully”) to the user.

When React Router swaps components, the DOM changes completely, but the browser’s focus often remains on the `` element or gets lost in the void. A keyboard user has to manually tab all the way through the navigation bar again to reach the new page content.

Architects enforce a global routing effect. On every route change, React must programmatically call .focus() on the top-level <h1> of the new page (which requires adding tabIndex="-1" to the H1 so it can receive programmatic focus). This instantly drops the screen reader or keyboard user precisely at the beginning of the new content.

Historically, opening a link in a new tab via target="_blank" gave the newly opened page access to the window.opener object of the original page. This created a massive security vulnerability: the new page could maliciously execute window.opener.location = 'phishing-site.com', hijacking the user’s original tab without their knowledge.

React heavily warned developers to append rel="noopener noreferrer" to sever this connection. While modern browsers (Chrome 88+) now implicitly enforce `noopener` on `target=”_blank”`, architects still explicitly require it in React codebases to support legacy enterprise browsers and Safari versions.

React assumes total authority over its Virtual DOM tree. If an external library (like Google Maps, an Ad network, or jQuery) appends or deletes a child node inside a React-managed <div>, React will eventually attempt to update that node. Finding the expected DOM structure broken, React throws a fatal NotFoundError (or Invariant Violation) and crashes.

Architects isolate external mutations. You render a completely empty <div ref={containerRef} />. You use a useEffect to pass that DOM node to the third-party library, and you never pass React children into that div. Furthermore, you can use shouldComponentUpdate (or memoization) returning `false` to guarantee React never attempts to reconcile that specific subtree again.

Prototype Pollution occurs when developers use unsafe recursive merge functions (like deep-merging user payload data into Redux state). If an attacker sends a JSON payload with a key named __proto__, a naive merge function will traverse up to the global JavaScript Object.prototype and inject properties directly into it.

// Unsafe merge function causing Prototype Pollution
function unsafeMerge(target, source) {
  for (let key in source) {
    if (typeof source[key] === 'object') {
      if (!target[key]) target[key] = {};
      // DANGER: If key is "__proto__", this alters the global Object prototype!
      unsafeMerge(target[key], source[key]);
    } else {
      target[key] = source[key];
    }
  }
}