React

Lead Summary

React is a JavaScript library for building user interfaces, developed at Meta (Facebook). Its defining contribution is a single mental model that governs the entire rendering process: UI is a function of state — UI = f(state). When state changes, React re-executes the component function and derives a new description of the UI; the framework then works out the minimum set of DOM mutations required to reach that new state.

This declarative model stands in contrast to imperative DOM manipulation, where code specifies each step of how to update the interface. With React, developers describe what the UI should look like for a given state, and React determines how to achieve it — via its virtual DOM, diffing algorithm, and reconciliation engine.

React dominates the frontend landscape. Stack Overflow and ecosystem trend data consistently show it as the most widely used front-end library, with usage roughly double that of its nearest competitor, Vue. That ubiquity brings ecosystem breadth, job-market fit, and community resources — but also characteristic trade-offs in learning curve, tooling choices, and architectural complexity that this article traces in full.

Core Concepts

UI as a Function of State

The foundational mental model is straightforward: a React component is a pure function that maps application state to a declarative description of the UI. Developers don't imperatively update the DOM; they declare what the UI should look like for any state, and React calls that function whenever state changes to produce a new description.

This is the re-render mental model: "re-rendering" means the component function is called again with new state. The framework then handles optimization — deciding which parts of the actual DOM need to change.

"UI is a function of state" means you never manually update the DOM. You describe what the UI should be, and React works out the rest.

Declarative vs. Imperative

Declarative rendering differs fundamentally from imperative rendering. Imperative code says: "find this element, change its text, add a class." Declarative code says: "the heading should contain this text." The framework decides whether to create new DOM nodes or modify existing ones.

This shifts cognitive effort: developers think about what state implies rather than what sequence of DOM operations to perform.

Immutability as a Requirement

React's state model requires immutability. React uses shallow reference equality to decide whether a re-render is needed — if a state setter receives the same object reference, it skips the re-render. In practice this means state must be replaced entirely (using the spread operator or immer) rather than mutated in place. useState's setter API encodes this: it replaces state rather than patching it. Functional update patterns (setState(prev => ...)) let you access previous state safely without capturing stale closures.

Mechanism & Process

JSX: Syntax Extension, Not a Language

JSX is a syntax extension that allows HTML-like markup to be written inside JavaScript. Browsers cannot execute JSX natively; build tools (Babel, SWC) compile it into regular React.createElement() calls before shipping to the browser. This compilation step is non-negotiable — it is why React projects require a build pipeline.

The Virtual DOM and Diffing

When state changes, React:

1. Re-executes the component function to produce a new virtual DOM tree (an in-memory JS object representation of the UI)
2. Diffs the new tree against the previous one to identify the minimal set of changes
3. Commits only those changes to the real DOM in a single batched operation

Batching multiple state updates into one commit cycle reduces the expensive reflows and repaints that would occur if each update touched the DOM independently.

The diffing algorithm achieves O(n) complexity by relying on two heuristic assumptions: elements of different types produce different trees (and should be rebuilt), and developers can hint at element identity using the key prop. Stable, unique keys enable React to match old elements to new ones correctly — using array indices as keys undermines this and causes unnecessary remounts and state loss.

Render and Commit Phases

React separates its work into two distinct phases:

• Render phase — React runs component functions and compares the new output to the previous virtual tree. This phase can be paused and resumed (the basis of concurrent features).
• Commit phase — React applies the computed diff to the real DOM. Effects (useEffect, componentDidMount) run here, after the DOM has been updated.

This phase separation enables optimization strategies including time-slicing and Suspense streaming.

React Fiber: Incremental Rendering

React Fiber, introduced in React 16, replaced the original synchronous reconciliation engine with a priority-aware, interruptible one. The render phase can be split across multiple animation frames, allowing React to pause lower-priority work (like rendering a long list) to handle high-priority user input. This is what makes React's concurrent mode and features like startTransition possible.

The motivation is the UI rendering constraint: unlike infrastructure reconciliation (Kubernetes, Terraform), UI must maintain a 60 FPS frame budget — roughly 16ms per frame — to feel responsive. Fiber's incremental model adapts the declarative reconciliation pattern to these strict timing requirements.

React is Not FRP

Despite the word "reactive" in its name, React is not functional reactive programming. React uses a push-pull hybrid: state changes push invalidation flags onto components, then React pulls new UI by re-executing component functions and diffing the virtual DOM. True FRP (RxJS, SolidJS) treats values as observable streams that proactively notify dependents with fine-grained precision. React's batched re-render model trades fine-grained tracking for predictability and simpler mental models.

Components & Structure

Function Components Are Standard

Function components have fully replaced class components for essentially all modern React development. With hooks, function components can manage every concern that previously required class-based inheritance hierarchies — state, lifecycle effects, context, and refs. Class components are not deprecated, but they are no longer the recommended pattern.

The mental model shift from class to function components is also a shift from lifecycle-based thinking to dependency-based thinking. Hooks like useEffect ask "what state does this effect depend on?" — not "when in the lifecycle should this run?"

Hooks

Hooks are the mechanism by which function components access React features. The most fundamental are:

• useState — local mutable state, with an immutable setter API
• useEffect — synchronize a component with an external system; runs after commit; controlled by a dependency array
• useContext — read from the nearest context provider
• useMemo / useCallback — memoize computed values and stable function references

The Rules of Hooks require that hooks are called at the top level of function components — never inside loops, conditionals, or nested functions. This constraint ensures consistent hook ordering across renders and is enforced by the eslint-plugin-react-hooks linter rule.

Explicit dependency arrays in useEffect, useMemo, and useCallback are a common source of bugs. Missing dependencies cause stale closures where functions capture outdated values. The exhaustive-deps ESLint rule catches these statically.

Custom Hooks

Custom hooks encapsulate related useState and useEffect calls into named, reusable functions — useFetch, useForm, useEventListener. This pattern lifts stateful logic out of the component rendering function, improving code reuse, testability, and separation of concerns.

Custom hooks have effectively replaced higher-order components (HOCs) and render props as the primary mechanism for sharing stateful logic across components. HOCs introduced indirection through wrapper components; hooks compose directly inside function bodies.

Error Boundaries

Error Boundaries are React's mechanism for fault isolation — the frontend analog of a backend circuit breaker. An Error Boundary wraps a subtree; if rendering throws, the boundary catches it, displays a fallback UI, and prevents the error from propagating to parent components. They can wrap top-level routes (showing a "Something went wrong" page) or individual widgets (protecting the rest of the application from a single failure).

One constraint: Error Boundaries must be implemented as class components. There is no hooks-based equivalent, which limits their integration with modern React patterns. The community library react-error-boundary provides a hooks-friendly wrapper.

React 19 Actions add automatic error boundary integration for server actions: when an action throws, React propagates the error to the nearest error boundary without manual try/catch.

Composition Patterns

React's composition model includes several well-established patterns:

• Compound components — a group of components that share implicit state via Context, modeled after HTML's <select> / <option> relationship. Libraries like Radix UI use this pattern extensively.
• Context for dependency injection — Context provides values to any descendant without prop threading. It functions as a built-in dependency injection container.
• Layout components — components whose sole responsibility is composing and arranging children, with no data logic of their own.

State Management

The Recommended Gradient

The recommended workflow is to start with local component state (useState or useReducer) and only lift state when another component genuinely needs access to it. State is lifted to a shared ancestor, then to Context, and only moved to a dedicated store when disparate components across the application all require access. This "lift when needed" approach avoids premature abstraction.

React Context: Middle Ground with Limits

React Context avoids prop drilling for data accessed by multiple components scattered across the tree, without the boilerplate of full state management libraries. It is appropriate for moderately deep sharing (roughly 3–4 levels) and infrequent updates.

Its key limitation: all consumers of a Context re-render whenever the context value changes. This makes it unsuitable for high-frequency state (e.g., real-time cursor positions or input streams). Large applications with many developers, complex state requirements, or high-frequency updates benefit from dedicated libraries that support granular subscriptions.

Redux: Enterprise Standard

Redux Toolkit remains the dominant choice in large enterprise applications with five or more developers, long-lived codebases, or complex state requirements. Its strict unidirectional patterns, middleware ecosystem, and DevTools time-travel debugger make state changes traceable and auditable. Redux adoption has plateaued in smaller projects but continues as an enterprise standard.

The unidirectional Flux architecture Redux implements — actions → dispatcher → stores → views — was developed at Facebook to solve cascading-update problems in MVC, where bidirectional data dependencies (e.g., marking a thread read must update both the thread model and the unread count) caused unpredictable cascading changes.

Modern Alternatives

For simpler applications, Zustand and Jotai have surged in adoption with lighter APIs. Zustand uses selector-based subscriptions to prevent unnecessary re-renders; Jotai uses atoms as the unit of state with derived-atom composition. For URL state, useSearchParams makes query parameters the source of truth — important for shareable and bookmarkable application state.

Server-Side Rendering and React Server Components

The Hydration Problem

Traditional SSR with React sends pre-rendered HTML to the client, then the client downloads JavaScript, re-executes the entire component tree to attach event handlers, and restores framework state. This hydration step doubles work: the server renders the HTML, the client re-renders the same tree. The page looks ready but isn't interactive until hydration completes.

React 18's selective hydration via Suspense addresses this by hydrating high-priority interactive components first and deferring lower-priority content. Wix's implementation reported a 20% reduction in JavaScript payload and roughly 40% improvement in INP (Interaction to Next Paint) using selective hydration with Suspense and streaming.

React Server Components (RSC)

React Server Components execute exclusively on the server and never re-render. Their output is serialized into the RSC Payload — a JSON-based format containing rendered instructions and references to Client Components — which is transmitted to the client. Client Components are loaded from the JS bundle and hydrated into the tree; the static Server Component regions require no JavaScript at all.

Key properties of Server Components:

• Direct backend access — database queries, filesystem reads, and private API calls happen directly in the component render function; credentials never reach the client
• Cannot use hooks — useState, useEffect, useContext, event listeners, and browser APIs are unavailable; interactive logic must live in Client Components
• Server wraps Client — Server Components can render Client Components as children (passing them as props or children); Client Components cannot import Server Components directly

Streaming with Suspense

Suspense boundaries in Server Components enable streaming and progressive rendering. When a Server Component awaits a promise, it suspends at that boundary while the framework continues rendering other tree branches in parallel, then streams completed sections to the client incrementally. Multiple Suspense boundaries allow different page sections to arrive and become interactive at different rates, substantially improving perceived performance for data-heavy pages.

Next.js as the Primary RSC Runtime

As of 2024–2026, Next.js App Router is the primary production implementation of React Server Components. RSC is a React feature but requires a framework-level integration to handle the server execution, routing, and serialization — React itself does not include a server runtime. Next.js Server Actions are stable and production-ready as of Next.js v13/v14, recommended for form submissions and component-level mutations.

Developer Tooling

The Build Pipeline

React development requires a build step that handles:

• JSX compilation — Babel or SWC transforms JSX into JS function calls
• TypeScript — compiled separately from type-checking; tsc --noEmit for type validation, swc or esbuild for the actual transform
• Bundling — Vite has become the default for non-framework React projects; Webpack remains common in enterprise and legacy codebases; Turbopack is Next.js's Rust-based bundler for large monorepos

Fast Refresh

React Fast Refresh preserves component state during module edits in development. When a file changes, Fast Refresh re-renders only the updated component while keeping its local state intact — form input values, modal open/closed state, and other ephemeral UI state survive the edit. This requires both the Babel transform and the webpack (or Vite) plugin to be configured.

React Strict Mode

<StrictMode> double-mounts components in development to surface effects that don't properly clean up. The double-mounting only occurs in development builds — production has no performance penalty. This intentionally exposes impure side effects early, ensuring components are resilient to remounting (which concurrent mode may trigger in production).

Testing

React Testing Library's Philosophy

React Testing Library (RTL) was built on the principle that tests should resemble how users interact with the application. Tests exercise rendered output and user behaviors — clicks, typing, reading — not implementation details like component state, props, or method calls. This makes tests more likely to catch real bugs while being more resilient to refactoring.

RTL explicitly avoids shallow rendering: it renders the full component subtree, including all children, context providers, and state managers. This forces realistic integration tests that catch prop-contract mismatches and configuration errors that unit tests would miss.

The primary query method is getByRole, which locates elements by their ARIA role — the same way assistive technologies navigate the page. This makes RTL testing inherently accessible.

Reception & Influence

The Ecosystem Trade-off

React is deliberately a view library rather than a full framework. It handles rendering; everything else — routing, state management, data fetching, build tooling, server infrastructure — requires external choices. This explicit trade-off between flexibility and decision fatigue is central to React's character.

The result is ecosystem fragmentation: multiple competing solutions for every layer (Redux/Zustand/Jotai for state; React Router/TanStack Router for routing; Webpack/Vite for bundling; React Query/SWR for remote state). Teams must make architectural decisions at every layer without framework guidance. Unlike Vue or Svelte, which provide strong defaults and more cohesive tooling, React places higher cognitive burden on developers to construct a coherent mental model of the full application architecture.

Market Position and the Signals Debate

React remains the most widely used frontend library. However, a significant architectural shift has occurred across the ecosystem since 2023: by 2024–2026, signals-based fine-grained reactivity has become dominant in competing frameworks — SolidJS, Qwik, Angular (v19+), Vue 3, and Svelte 5 have all adopted signal-based models where only the precise data dependencies update when state changes, without re-executing full component functions.

React's response is not to adopt signals but to introduce the React Compiler (v1.0 released October 7, 2025): a build-time tool that automatically applies useMemo, useCallback, and React.memo() without manual developer intervention, achieving similar performance goals through a different mechanism. This is a deliberate architectural divergence — React preserves its coarse-grained, component-function model while eliminating the manual memoization overhead that previously made fine-grained frameworks appear more attractive.

The React team is also working on View Transitions API integration in the canary build, with stable first-class support expected in 2026.