React Interview Questions

A render is React calling components to calculate the next UI description from props, state, and context. That calculation must stay pure and may be restarted. React then compares the next tree with the previous one, and during commit applies necessary host changes such as DOM mutations and refs. Browser layout and paint happen after React's work; component execution does not imply a DOM update.

Each render receives fixed state values. Calling a setter queues work for a future render; it does not change the state variable inside the current event handler or closure. That is why several setCount(count + 1) calls from one render all calculate from the same count. Functional updates express a transition from the queued previous value when the next state depends on it.

React needs to call rendering code whenever it must calculate UI, and modern rendering work may be repeated, paused, or abandoned before commit. A pure component returns the same JSX for the same inputs and does not mutate external state during render, so those behaviors remain safe. User-caused side effects belong in event handlers; render-caused synchronization with external systems belongs in Effects.

Render is the pure calculation phase: React calls components and determines the next tree. Commit is when React applies the resulting host changes, updates refs, and runs the appropriate effect lifecycle. A component can render without producing a DOM mutation, and work calculated during concurrent rendering can be discarded before commit. Browser layout and paint are separate stages after DOM changes.

A component renders initially when its tree is mounted. Later it can render because its own state changed, an ancestor rendered it again, a consumed context value changed, or a subscribed external store notified it. A render does not mean the DOM changed. Memoization can skip some ancestor-driven renders, but a component's own state and consumed context still update it.

By default, when a component renders, React evaluates the child elements it returns and renders that subtree. React can reuse work at explicit or compiler-created memo boundaries when relevant inputs are unchanged, and already-created children passed through composition may keep stable element identity. Treat this as performance behavior, not correctness: children must be pure and correct whenever React calls them.

React associates state with a component identity in the rendered tree, determined primarily by element type, position among siblings, and key. If that identity remains stable, React preserves state across renders. If the type or key changes, or the component moves to a different identity position, React treats it as a different instance, cleans up the old one, and initializes new state.

A component is a function or class React can call to calculate UI. A React element is the immutable description produced by JSX or createElement: it records a type, props, and key. Rendering a component returns elements; React uses those elements to construct and reconcile the tree. Elements are descriptions, not DOM nodes and not mounted component instances.

JSX is syntax for expressing a React element tree alongside JavaScript. A build transform converts it to calls in the JSX runtime that create element descriptions containing the type, props, and key. JSX is neither HTML nor a template string: JavaScript expressions run while the component renders, and React later interprets the resulting elements for the target renderer.

Props are inputs owned by the parent for that render; the child must treat them as read-only. State is memory owned by a component identity and updated through React. Both are snapshots and both can differ on the next render. The design question is ownership: keep one source of truth at the lowest boundary that coordinates every reader and writer.

Composition lets callers supply meaningful UI pieces through children or named slots while the parent owns layout and behavior. A large boolean-and-variant prop matrix creates combinatorial states, unclear precedence, and a brittle abstraction. Good APIs keep invariants inside the component, expose a small stable contract, and use composition only where callers genuinely need structural freedom.

A controlled component receives its current value and reports requested changes, so the parent owns the source of truth. An uncontrolled component owns its state internally, often initialized with a default value, and may expose a ref or final value. Controlled APIs coordinate validation and cross-field behavior; uncontrolled APIs reduce update coupling. A reusable component should not silently switch modes during its lifetime.

React preserves state when the same component type occupies the same identity position, even if different source-code branches produced it. It resets state when the type or key at that position changes. To predict behavior, sketch the resulting element tree for each condition. Avoid defining component functions inside another component because that creates a new component type every render.

Type the smallest public contract and encode mutually exclusive modes with discriminated unions instead of optional-prop combinations. Use explicit event and ref element types, model children according to the actual composition contract, and make callback payloads domain-specific. React.FC is optional; plain functions often preserve clearer generics and do not imply a children prop you may not support.

Keep state local when only one subtree needs it; locality reduces coupling and render reach. Lift it to the nearest common owner when multiple peers must coordinate one source of truth. Do not lift state preemptively into a page or global store. Ask who reads it, who writes it, whether it must survive navigation, and whether a URL, server cache, or form boundary owns it better.

Derived data can be calculated from current props or state, such as a filtered list or full name. Storing another copy creates two sources of truth and a synchronization problem—often an unnecessary Effect and extra render. Calculate cheap derived values during render; memoize only measured expensive work. Store a value separately only when it represents independent user intent or history.

Group values that always change together and separate values with independent lifetimes. Avoid contradictory booleans such as isLoading, isSuccess, and isError when a discriminated status can represent one valid state. Normalize large relational collections when updates otherwise require duplicating entities. A reducer helps when named events must preserve several invariants atomically.

React queues state updates and normally processes them together before the next render, avoiding an intermediate render after every setter call. Batching changes render frequency, not snapshot semantics: three setCount(count + 1) calls from one handler still enqueue the same replacement value. Three functional updates, setCount(c => c + 1), compose against the queued value and produce three increments.

Use setState(previous => next) when the next value depends on the previous value, especially for multiple updates in one event or callbacks that run later. React applies updater functions in queue order to the pending state. If the next value comes entirely from current event data or props, a direct replacement is often clearer.

Local UI state belongs to a component interaction; shared client state coordinates client-owned behavior; server state is a cached view of remote authority with freshness rules; URL state is navigable and shareable; form state is an editable draft; cache state has eviction and invalidation semantics. Choosing one global store for all six hides different lifetimes and correctness rules behind one API.

If work happens because the user performed a specific action—submit, purchase, send—run it in that event path. If a component being present or a reactive value changing requires synchronization with an external system, use an Effect. Moving event-specific work into an Effect loses the cause, can repeat on remount, and creates indirect state choreography.

React associates Hook state with the component and the order of Hook calls. Conditional, looped, or nested function calls can change that order between renders and attach state to the wrong call. Call Hooks unconditionally at the component or custom-Hook top level, and express conditional behavior inside the Hook or by splitting components. The official lint rules enforce more than naming style—they protect runtime correctness.

useState is simplest for independent values and direct replacements. useReducer helps when several fields change together, transitions have domain names, or invariants deserve one pure transition function. It centralizes update logic but does not make state global or automatically faster. If the reducer becomes a switch over trivial setters, it adds ceremony without a clearer model.

A ref is a stable mutable cell across renders. Updating ref.current does not schedule a render, so refs fit DOM nodes, timer IDs, external instances, and bookkeeping not used to calculate visible UI. State belongs to values whose changes must appear in rendering. Reading or writing refs during render generally breaks purity; use them from events, effects, or ref callbacks.

A common pattern reads a ref during render and updates it in an Effect after commit, so the next render sees the last committed value. That timing is the behavior—not a special previous-value feature. If previous state is needed to calculate the next state, use a reducer or functional update instead. Avoid ref-based shadow state that bypasses React's rendering model.

When a provider's value changes by Object.is comparison, React updates consumers that read that context, regardless of an ancestor memo boundary. A newly created object value changes every provider render. Stabilizing identity can help, but the architectural fix is often splitting contexts by change frequency, narrowing provider placement, or moving rapidly changing data to a selector-capable external store.

Not necessarily. useMemo caches a calculation result between renders when dependencies are unchanged; it does not stop the component from rendering. Measure the calculation and render path first. Memoization adds dependency comparisons, retained memory, and correctness risk from stale dependencies. With React Compiler enabled, automatic memoization further reduces the need for manual useMemo, which remains an optimization rather than semantic storage.

Context: React Compiler 1.0 can automatically memoize calculations; manual useMemo remains available for precise control and non-compiler builds.

useCallback caches a function identity, not its result and not the work inside it. It can help a memoized child avoid a prop change or stabilize a dependency, but wrapping every handler adds code and dependency risk without benefit when consumers render anyway. Prefer simpler code, profile the path, and account for React Compiler automatic memoization where enabled.

A good custom Hook owns one coherent stateful or synchronization concern, exposes a small domain contract, and leaves UI composition with components. It makes lifecycle, dependencies, and error behavior explicit. A Hook that mixes fetching, analytics, navigation, and form state hides ownership and becomes difficult to test. Reuse is a consequence; clarity of the boundary is the primary reason.

Every render creates functions that close over that render's props and state snapshot. If a timer, listener, promise callback, or memoized function runs later, it still sees those captured values unless it is recreated with correct dependencies or reads the latest value through an intentional pattern. Fix the ownership or dependency model; do not suppress the linter and hope the closure stays current.

An Effect describes how a committed render synchronizes with an external system such as a subscription, browser API, timer, network connection, or third-party widget. React runs setup after commit, runs cleanup before resynchronizing with changed dependencies, and cleans up on unmount. If there is no external system, the code probably belongs in render or an event handler.

fullName is fully determined by current props, so calculate it during render. Storing it creates another source of truth: React first commits stale fullName, the Effect sets it, and React renders again. The dependency array only maintains the synchronization problem. Reserve state for independent information and Effects for external systems.

Dependencies are every reactive value read by the Effect's setup. React compares them with Object.is to decide when that external synchronization must be torn down and recreated. You do not choose dependencies to control timing; change the code so the desired dependency model is truthful—move event work to events, derive values during render, split independent Effects, or stabilize genuine inputs.

Cleanup runs before React applies the Effect setup again with changed dependencies and when the component unmounts. In development Strict Mode, React also performs an extra setup-cleanup-setup cycle to expose missing teardown. Cleanup should symmetrically disconnect, unsubscribe, clear, or cancel what that setup created; it should not perform unrelated global reset work.

In development, Strict Mode intentionally runs an extra Effect setup and cleanup cycle to reveal code that cannot safely disconnect and reconnect. Production does not keep that extra cycle. The fix is not a ref that suppresses setup; make cleanup undo setup and make the external operation safe for remounting. Duplicate irreversible user actions usually belonged in an event handler.

Context: This is a development-only Strict Mode behavior; production setup follows the committed lifecycle.

Effects can start request A, then request B after input changes; if A finishes last, it can overwrite B's newer result. Cleanup should abort obsolete work where supported, and the completion path must ignore results that no longer match the active request. In production, prefer a framework loader or query/cache layer that also handles deduplication, freshness, retries, and navigation races.

A chain where Effect A sets state for Effect B creates indirect control flow, extra commits, fragile dependencies, and intermediate states the user can observe. If the values are derivable, calculate them in render. If one user or server event causes a multi-field transition, update it together—often through a reducer. Keep separate Effects only for genuinely independent external synchronization processes.

Reconciliation relates the previous and next React trees so React can decide which component identities and host nodes to reuse, update, insert, or remove. Type, position, and keys guide that relationship. It is broader than a DOM diff: reconciliation also determines component lifetime and state preservation. The commit phase later applies the resulting host changes.

Keys tell React which sibling in the next list corresponds to which sibling in the previous list. A stable domain key lets state and DOM association follow an item through insertion, removal, and reordering. Keys need only be unique among siblings, but they must be stable across renders. Generating a new key during render makes every item appear new and resets state.

An index identifies a position, not the domain item occupying it. If items are inserted, removed, filtered, or reordered, React can reuse a component and its local state for a different item, causing wrong input values, focus, or animation state. An index is acceptable for a truly static list with no reordering and no item identity; a stable data ID is the normal choice.

A changed key gives the element a new identity. React unmounts the previous component, runs its cleanup, discards its state, mounts a new instance, and creates the necessary host work. This can deliberately reset a form for a new entity, but using unstable keys causes lost input, repeated subscriptions, broken focus, and unnecessary DOM work.

State is stored by React for an identity position in the rendered tree. Moving the same-looking JSX to a different parent or sibling identity can remove the old component and create a new one, so state resets. If state must follow a domain entity, preserve its stable keyed position or move the state to an owner whose lifetime matches the entity.

Reconciliation is React's process for relating previous and next element trees, including component identity and state lifetime. DOM updating is only the host mutation work selected from that process and applied during commit. A parent and many children may render, yet if their host output is unchanged React may perform no DOM mutations. The browser separately handles style, layout, paint, and compositing.

Defining a component inside another component creates a new function object each parent render. React sees a different element type at that position, so it remounts the subtree, resets state, and repeats setup and cleanup. Define component types at module scope and pass changing data through props. An inline callback or render function is different—it is a value, not necessarily an element type.

React.memo can reuse a component's previous result when its parent renders and props compare equal by Object.is. The component still renders for its own state updates and consumed context changes, and React may render it for other reasons because memoization is an optimization. New object or function props defeat shallow equality. React Compiler can supply equivalent optimization automatically when enabled.

A re-render is work, but it is not automatically a performance problem. Many component calculations are cheap and produce no DOM changes. Cost comes from tree size, expensive calculations, unstable dependencies, broad context or state updates, host mutations, layout, paint, and synchronous third-party work. Measure interaction latency and profiles before trading simplicity for memoization.

Reproduce the exact interaction with production-like data and record a browser Performance trace plus React DevTools profile. Determine whether time is in JavaScript, React rendering, a commit, layout/paint, network, or third-party work. Identify why the expensive subtree rendered, form one hypothesis, make the smallest architectural or algorithmic change, and remeasure the user-visible latency and regressions.

Inspect which commits correspond to the slow interaction, their duration, which components rendered, and why inputs changed. Look for a broad subtree updated by high state or context, an individually expensive calculation, repeated commits caused by Effects, or unstable props defeating a bailout. Correlate with the browser trace because React profiles do not explain network waits, layout, paint, or third-party scripts alone.

An update renders the owning component and, by default, its subtree. Moving ephemeral state closer to the components that need it reduces render reach and coupling without memoization. Before optimizing props, ask whether hover, draft input, dialog state, or selection was lifted too high. Shared state should still live at the lowest boundary that genuinely coordinates all consumers.

Profile which consumers update and inspect whether the provider recreates a composite object on unrelated changes. Stabilize genuine provider values, split contexts by responsibility and change frequency, narrow provider placement, and separate state from dispatch where useful. For high-frequency or large shared data, a selector-based external store can notify only affected readers. Do not memo every consumer before fixing the ownership boundary.

Use windowing: render only visible rows plus a small overscan buffer, represent total height with spacers, and recycle positions as the viewport moves. Define stable item identity, row measurement for variable heights, keyboard and screen-reader behavior, focus retention, and scroll restoration. Pagination bounds data transfer; virtualization bounds DOM and render work. React.memo alone leaves the huge DOM mounted.

Split code at route or feature boundaries that materially reduce initial JavaScript, not every small component. Provide a stable loading experience, preload likely next paths, and track chunk size, cacheability, and failed dynamic imports. Excessive splitting adds request and Suspense coordination overhead. Measure parse, compile, execution, and interaction readiness—not only compressed bundle bytes.

React DevTools shows component render and commit work. The browser Performance panel shows the full main-thread task, including JavaScript outside React, style recalculation, forced layout, paint, and compositing. If a small commit triggers expensive layout on a massive DOM, memoization misses the bottleneck. Correlate timestamps and test whether the limit is component work, DOM size, CSS/layout, or network.

Concurrent rendering lets React prepare multiple versions of UI with priority-aware, interruptible render work. A lower-priority render can pause or restart so an urgent input update stays responsive; only a completed consistent tree commits. It does not mean component functions run simultaneously on multiple JavaScript threads. Purity is what makes restartable calculation safe.

useTransition marks selected state updates as non-blocking. React can interrupt that render to process urgent work such as typing, while isPending supports intentional pending feedback. It does not make expensive JavaScript faster and should not control a text input's own value. Use it when rendering the destination is costly and keeping the current interface responsive is better than blocking.

useDeferredValue lets an urgent render use the old value while React prepares a lower-priority render with the new one. It has no fixed delay and does not prevent requests from firing. Debouncing waits for input to settle before invoking work and can reduce calls. Choose based on whether the bottleneck is render responsiveness, request volume, or both.

A Suspense boundary defines where React may show fallback UI while a compatible child is not ready, and coordinates reveal during client rendering or streaming SSR. It does not fetch data, choose cache semantics, or make an arbitrary useEffect request suspend. The framework or data source must integrate with Suspense. Place boundaries around coherent user experiences to avoid flashing the whole page.

React Compiler 1.0 is a stable build-time optimizer that analyzes component and Hook code and applies granular memoization automatically. It reduces routine useMemo, useCallback, and React.memo work, but it does not fix expensive algorithms, huge DOMs, network waterfalls, or broken state ownership. Adopt it incrementally, respect the Rules of React, test behavior, and verify performance rather than assuming every component improves.

Context: React Compiler 1.0 became stable in October 2025 and supports incremental adoption; integrations remain build-tool specific.

Server Components render ahead of the client bundle in a separate environment, can access server-side data, and send rendered output rather than their component code to the browser. Interactive state, Effects, and browser APIs belong in Client Components. Values crossing the boundary must be serializable by the integration. React 19 stabilizes the component model, while bundler/framework implementation APIs can still change between minors.

Context: Server Components are stable in React 19; production routing, caching, server functions, and bundling are supplied by a framework, whose underlying RSC APIs require careful version alignment.

A server boundary helps when rendering needs server-only data or heavy noninteractive libraries, and the output can cross as serializable UI without shipping that code to the client. It is less useful for highly interactive, offline, or rapidly client-updated behavior. Measure client JavaScript, waterfall removal, cache behavior, navigation latency, and server cost. A Server Component is not automatically a security boundary for data passed to clients.

SSR renders a React tree to HTML for the initial response; interactive client components still load JavaScript and hydrate. Server Components define components that do not enter the client bundle and whose rendered result can compose with Client Components. Frameworks often combine RSC, SSR, streaming, and routing, but they solve different problems: initial HTML delivery versus the server/client component graph.

Hydration lets React attach behavior to server-rendered HTML while reusing that DOM. The first browser render must match the server output in structure, text, attributes, and stable IDs. Dates, locale, random values, browser-only storage, invalid HTML, request-specific data, extensions, and CDN rewrites can diverge. Find and remove the nondeterministic source; suppression is only a narrow escape hatch.

Streaming SSR can send the ready application shell first, then stream later Suspense boundary output as dependencies resolve. This improves progressive delivery but introduces boundary placement, fallback stability, error recovery, caching, abort, and hydration coordination decisions. It does not remove server latency or client JavaScript cost. Frameworks determine the data, routing, and deployment integration around React's server APIs.

useEffectEvent lets an Effect call non-reactive logic that always sees current props and state without making those values dependencies of the synchronization process. It is useful when connection setup depends on roomId but a notification should use the latest theme. It is not a general dependency escape hatch, cannot be passed around arbitrarily, and does not replace normal user event handlers.

Context: useEffectEvent became stable in React 19.2.

Fetching in an Effect starts after render, repeats boilerplate for loading and races, and can create parent-child waterfalls. Route data often belongs in a framework loader or server boundary; shared client data often belongs in a query/cache layer with deduplication, freshness, cancellation, and invalidation. An Effect remains reasonable for small client-only synchronization where the component truly owns the request lifetime.

Client state is authoritative inside the client for interactions such as a draft or open panel. Server state is a local snapshot of remote authority: it can become stale, be refetched, invalidated, shared, or conflict with mutations from elsewhere. A query cache models those semantics better than manually copying responses into a generic global store. Optimistic UI is a temporary client projection, not a transfer of authority.

Apply an optimistic projection only when success is likely and the rollback or correction is understandable. Give the mutation a stable identity, show pending status, prevent accidental duplicates, and reconcile with the authoritative response. On failure, restore or mark the item and offer recovery. For conflicting collaborative data, define merge/version rules instead of assuming last response wins.

A controlled input mirrors its value in React state and is useful when rendering, validation, or other fields depend on each change. An uncontrolled input lets the DOM hold the live value and reads it at a boundary such as submit, reducing render coupling. Both can be accessible and validated. Large forms often combine uncontrolled field storage or field subscriptions with React-owned form-level status.

Profile one keystroke, then stop routing every field change through one form component. Give fields local or uncontrolled draft storage, subscribe only affected fields and summaries, and run expensive validation at deliberate boundaries or in incremental slices. Preserve accessible labels, error association, focus-to-error, server validation, and draft recovery. Virtualize only if hidden field DOM itself is large and navigation semantics remain intact.

A cache needs stable query identity, freshness windows, deduplication, cancellation, invalidation after mutation, garbage collection, persistence rules, and authorization-aware scoping. Retries need bounded backoff and method safety; they must not amplify a failing dependency. Decide whether stale data can remain visible, how offline or partial failure appears, and how telemetry distinguishes cache hit, revalidation, and network failure.

A component test should exercise the public behavior: render accessible output, perform realistic user interactions, and assert the resulting UI, callback, or navigation. Query by role and label where possible because that resembles how users and assistive technology find controls. Avoid asserting private state, exact component trees, or how many times a Hook ran unless that is itself an external contract.

Unit-test pure domain transitions and utilities; component/integration tests cover rendered behavior across components, state, and mocked network boundaries; E2E tests protect a small set of critical journeys in the deployed stack. The goal is risk coverage, not a fixed ratio. Too many isolated component mocks miss integration failures, while too many broad E2E tests become slow and hard to diagnose.

Mock the network, clock, browser capability, or external service boundary when control and determinism matter. Prefer request-level mocks over mocking the data Hook implementation so caching, loading, and error UI still run. Do not mock every child component—the test then verifies wiring rather than behavior. Keep mock responses contract-shaped and include latency, empty, error, and cancellation cases.

Trigger the user action, await the resulting accessible UI state, and let the test utility flush React work through its supported APIs. Control network responses and timers explicitly. Avoid fixed sleeps, un-awaited user events, shared mutable fixtures, and assertions that race intermediate loading states. A flaky test often reveals an application race or missing ownership boundary, so diagnose it rather than only increasing timeout.

Choose the native element that already carries the required semantics and keyboard behavior: button, link, input, heading, list. Give controls programmatic labels, preserve visible focus, expose validation and status, and test with keyboard and a screen reader. ARIA can describe a custom widget but does not add behavior; a div with role=button still requires keyboard activation and focus management.

Use a real dialog pattern with an accessible name. On open, move focus to a meaningful element; keep Tab navigation inside while modal; support Escape and an explicit close control; prevent background interaction; then restore focus to the trigger when safe. Handle nested portals, scroll lock, destructive confirmation, and route changes. Prefer a proven accessible primitive because focus edge cases are extensive.

Use the ARIA combobox pattern with a labelled input, controlled popup state, listbox relationship, active option indication, and documented Arrow, Enter, Escape, and Tab behavior. Keep DOM focus predictable, announce result count/loading changes without noise, preserve typed text, and expose errors. Add debounce, cancellation, stale-result guards, caching, and mobile/touch behavior without breaking keyboard semantics.

Context solves value distribution without prop drilling; it does not define state transitions, caching, selectors, persistence, or server synchronization. A reducer plus Context can be enough for modest low-frequency client state. An external store becomes useful when independent subscriptions, selector-based updates, middleware, time-travel/debugging, cross-root ownership, or established team conventions justify the added dependency.

Any changed composite value can update every consumer, and unrelated responsibilities become one dependency and test fixture. Split contexts by cohesive ownership and change rate, narrow provider placement, keep auth authority separate from presentation preferences, and move high-frequency dashboard data to a selector-capable store. The goal is clearer boundaries first and reduced render reach second.

Redux fits substantial shared client state with many writers, complex transitions, normalized entities, cross-feature coordination, or strong debugging and middleware needs. Redux Toolkit removes much boilerplate. It should not absorb every local input or replace a server-data cache. Compare it with Context plus reducer, an external store, URL state, and the team's operational needs before adding global ownership.

Compound components work when a control has recognizable parts—Tabs, List, Trigger, Panel—that need shared state but flexible composition. A private context can coordinate IDs, selection, and keyboard behavior while the public API remains declarative. Keep allowed structure and accessibility invariants clear. For a simple component, named props or children are often easier than an entire compound vocabulary.

Offer controlled open/onOpenChange plus an optional uncontrolled default, semantic Trigger/Content/Title/Description/Close parts, and a portal/layer manager. The primitive owns focus, Escape, outside interaction, scroll locking, labelling, and restoration. Product code owns business actions and copy. Define nested-dialog and route-change behavior; avoid an imperative global openModal payload that erases type and ownership boundaries.

Warning signs include boolean prop matrices, callbacks for every internal step, styling escape hatches that bypass invariants, and branches for unrelated domains. Split stable primitives from domain components, encode valid variants, and use composition at deliberate seams. Reuse should reduce coordinated change; if every caller needs exceptions, the abstraction has grouped code by visual similarity rather than shared behavior.

Define a domain-facing contract for operations and state, then provide adapters for HTTP, local storage, analytics, or framework navigation at a boundary. Components consume the contract through props, context, or a focused Hook. This keeps tests behavioral, migrations local, and server/client differences explicit. Do not introduce an interface for every function; invert volatile infrastructure dependencies that cross many features.

Declare the component as a generic function, infer T from items, and type callbacks such as getKey(item: T) and renderItem(item: T). Constrain T only when the component relies on a property; otherwise a required accessor keeps the component flexible. Polymorphic as props require careful ref and intrinsic-prop merging and are often unnecessary for domain components.

Model actions as a discriminated union so each event carries only its valid payload and the reducer narrows automatically. An exhaustive never check makes adding an event without handling it a compile error. Pair that with a state union when loading, success, empty, and error are mutually exclusive. Types cannot prove runtime server data, so validate external inputs at the boundary.

Separate input text, selected value, popup navigation, and remote query state. Debounce request start, abort obsolete work, guard response order, cache by normalized query, cap results, and define empty/error/offline UI. Implement combobox keyboard and screen-reader behavior, preserve focus, and measure input latency, request rate, cache hits, selection success, and errors. React is only one layer of this system.

Infinite scroll loads more data as a sentinel approaches the viewport but can still accumulate thousands of DOM nodes. Virtualization renders only a window regardless of loaded item count. Large feeds often need both, plus cursor pagination, in-flight and end guards, error retry, focus and screen-reader strategy, deep linking, scroll restoration, and an alternative path when endless scrolling harms navigation.

Define a column schema and stable row IDs; push large sort/filter/page operations to an API; window visible rows and possibly columns with measured sizes and overscan. Keep selection independent of mounted rows, preserve keyboard navigation and focus as cells recycle, expose table semantics or an accessible grid pattern, and handle resize, sticky regions, loading gaps, export, and scroll restoration. Profile DOM, memory, and interaction latency.

Do not call setState for every message. Parse and normalize updates outside broad component state, coalesce by entity, and publish snapshots at an intentional cadence such as animation frames or a lower sampling rate. Use selector subscriptions so only affected widgets update. Bound buffers, drop or aggregate obsolete telemetry, resync after gaps, and expose connection lag. Capacity is messages in, processing cost, retained history, and renders out.

Give every outgoing message a client ID and pending/failed/sent state, reconcile it with server identity, and define ordering under reconnect or clock skew. Page older history without breaking the scroll anchor, virtualize long conversations, coalesce presence/typing updates, and preserve draft state. Include retry idempotency, attachment progress, offline behavior, accessibility announcements, abuse controls, and telemetry for delivery lag and failure.

Model durable inbox items separately from transient toasts. Give events IDs, priority, deduplication, expiry, and actions; bound the visible toast queue; pause dismissal for interaction; and use an appropriate live region without announcing a burst of low-value updates. Keep success feedback near the triggering control when possible. Persist read state server-side if it must cross devices and measure delivery and action outcomes.

Define a versioned schema for fields, layout, validation, conditions, and data mapping; keep it independent from React component implementation. Build an editor with undo/redo and draft persistence, and a renderer that maps schema primitives to accessible design-system components. Validate on client and server, migrate old schemas, sandbox extensions, localize labels/errors, and observe completion and field failure without collecting sensitive values.

Inventory usage and pain, establish tokens and a small set of accessible high-leverage primitives, and publish versioned APIs with examples, tests, and migration tooling. Adopt through touched-code and priority-flow migrations rather than a freeze. Provide compatibility wrappers and codemods, measure bundle and defect impact, establish contribution and deprecation governance, and partner with product teams so the system solves real delivery problems.

Microfrontends can align large autonomous teams with independent deployment and bounded domains. They add runtime coordination, duplicated dependencies, routing and state contracts, inconsistent UX, observability complexity, and migration overhead. Prefer a modular monolith and shared build when teams can coordinate. If adopted, define integration boundaries, dependency policy, design-system compatibility, failure isolation, performance budgets, and cross-team contracts before choosing a runtime technique.

React normally escapes interpolated text, but dangerouslySetInnerHTML tells it to insert raw HTML. Untrusted or incorrectly sanitized content can execute XSS through elements, attributes, URLs, or mutation paths. Sanitize on a trusted boundary with an allowlist designed for HTML, keep the dependency updated, consider Trusted Types and CSP as defense in depth, and never treat client sanitization as authorization.

All client code and state are controlled by the user, so hiding a route or button cannot grant or deny authority. The server must authenticate the request and authorize each operation and returned resource. Choose cookie or token storage based on threat model, CSRF, XSS, and deployment constraints; avoid placing secrets or privileged data in bundles. React renders the UX around security decisions—it is not the enforcement layer.

Keep dependency count and privileges small, pin and review lockfile changes, monitor advisories, generate provenance/SBOM where required, and test updates in staged builds. Restrict third-party scripts with CSP and isolation. Build-time public environment variables and source maps can expose data, so never bundle secrets. Security scanning supports—not replaces—ownership, threat modeling, and rapid patch/rollback capability.

An Error Boundary can catch rendering and lifecycle errors in its descendant tree and render fallback UI. It does not generally catch errors in event handlers, arbitrary async callbacks, server rendering, or the boundary itself; those need normal try/catch, rejected-state handling, framework error routes, or process-level reporting. Place boundaries around recoverable product regions and log component context without exposing sensitive data.

Catch the rejected lazy import at an error boundary, report the asset URL and release, and offer a deliberate retry or reload. A one-time cache-busted retry may help transient failures; repeated automatic retries can loop. Deploy immutable hashed assets with sufficient retention so old HTML still resolves, coordinate CDN invalidation, and avoid deleting prior chunks immediately during rollout.

Capture actionable JavaScript errors and component stacks, route and interaction performance, Core Web Vitals, long tasks, failed resources and APIs, and critical journey outcomes. Tag release, route, device class, and trace IDs so client and backend evidence joins. Sample high-volume signals, scrub personal data, define alert thresholds around user harm, and preserve source-map access securely. Telemetry must support rollback decisions, not merely dashboards.

Reproduce with realistic data and record a React profile. Identify which state or context update starts the commit, why unaffected widgets render, and whether expensive work or browser layout causes the delay. Move filter draft state to the smallest owner, split broad context, derive stable props, and memoize only measured expensive boundaries. Reprofile the same interaction and verify correctness, latency, and memory.

First determine whether the input's value update is blocked or only results lag. Record a browser trace and React profile while typing. Look for synchronous filtering, a high-owned state update rendering a large tree, request work on every keystroke, layout/paint, or third-party handlers. Keep input state urgent and local, defer or transition expensive results, debounce requests where appropriate, cancel stale work, and verify input latency.

Create a repeatable navigate-away cycle and compare heap snapshots after forced idle/GC in a profiling environment. Inspect retained component data, detached DOM, event listeners, timers, WebSocket or observer subscriptions, global registries, query caches, and closures. Confirm Effect cleanup and library disposal. Separate expected cache warm-up from unbounded growth, fix the retaining owner, and rerun enough cycles to verify a stable plateau.

Profile the provider updates and consumer set, then split values by ownership and change frequency—for example auth identity, theme, notification commands, and dashboard data. Narrow provider placement and separate state from stable actions where useful. Stabilize values only after the boundary is correct. Move high-frequency shared data to an external store with selectors so consumers subscribe to the exact slice they render.

Test a production build on representative mobile hardware and network. Trace bundle download, parse, compile, module initialization, hydration, React commits, long tasks, and third-party scripts. Use coverage and bundle analysis to remove or split code, move noninteractive work server-side where appropriate, stream useful HTML, defer third parties, and reduce hydration scope. Track interaction latency and errors, not only first paint.

The input may start request A and then B; network completion order is independent, so A can arrive last and overwrite B. Abort obsolete requests to save work and guard every completion against the latest query or request sequence for correctness. Debounce request creation, not input rendering. A query library can centralize keys, cancellation, deduplication, cache freshness, and navigation behavior.

Profile to confirm mount, DOM, layout, or data processing cost, then paginate or cursor-load data and virtualize visible rows with overscan. Move large sort/filter operations to a worker or server when appropriate, preserve stable IDs and selection outside mounted rows, and design focus, screen-reader, sticky-header, and scroll-restoration behavior. React.memo cannot make 50,000 DOM nodes cheap.

Reproduce with the production build and affected request context. Compare View Source with the browser's parsed DOM and React's first client inputs. Inspect dates, locale, random IDs, browser storage, feature flags, invalid nesting, request data, CDN rewrites, extensions, and mixed-version assets. Bisect the release and component boundary. Restore deterministic first output; do not broadly suppress warnings or switch the route to client-only rendering.

Measure incoming rate, processing cost, queue depth, render cadence, and acceptable staleness. Coalesce superseded updates by entity, sample telemetry, publish at animation-frame or product-specific intervals, and use selector subscriptions. Bound queues and define drop, aggregate, resync, or disconnect behavior under overload. Move parsing to a worker if it is material, and expose lag so silent stale UI is not mistaken for real time.

Map each Effect to the external system it synchronizes. Remove derived-state and event-driven Effects, combine updates into explicit transitions, and split independent capabilities into components or focused Hooks with clear lifetimes. If several Effects coordinate one workflow, model it as a reducer or state machine. Keep genuinely independent subscriptions separate. Use tests and profiling to preserve behavior during incremental extraction.