React Application Development Interview Questions

JSX compiles to plain JavaScript function calls -- `<div className="a">Hi</div>` becomes something like `React.createElement("div", { className: "a" }, "Hi")` (or a `jsx()` call with the modern transform). JSX is syntax sugar, not a separate templating language.

An element is a plain, immutable description of what to render (the object JSX compiles to); a component is a function (or class) that returns elements -- React calls your component functions to produce the elements it then renders.

Props are read-only inputs passed from a parent to a child component. A component must never mutate its own props -- one-way data flow means data flows down through props, and changes flow back up through callbacks the parent provides.

Keys let React's reconciliation algorithm match elements across renders to determine which items were added, removed, or reordered, rather than re-rendering the entire list from scratch.

If items are reordered, inserted, or removed, the index-to-item mapping shifts, so React can incorrectly reuse a DOM node (and its internal state) for a different logical item than before -- a stable, unique identifier from the data itself is safer.

Common mistake: Using the array index as `key` for a reorderable or filterable list, causing component state to attach to the wrong item after a reorder.

A fragment lets a component return multiple sibling elements without wrapping them in an extra DOM node like a `<div>`, avoiding unnecessary markup in the rendered output.

Composition means building complex UI by nesting and combining smaller components (often via the `children` prop) rather than passing every piece of data or behavior down through many prop layers -- it keeps intermediate components decoupled from data they don't use directly.

Passing a prop through several intermediate components that don't use it themselves, just to reach a deeply nested child. It can be avoided with composition (passing the component itself down as `children`/a prop) or with Context for genuinely widely-needed data.

JSX uses capitalization to distinguish a custom component (`<MyButton />`, compiled as a component reference) from a built-in host element (`<button />`, compiled as a string tag name) -- a lowercase custom component name would be misinterpreted as an HTML tag.

Breaking a UI into well-scoped pieces where each component has a single clear responsibility and owns only the state it genuinely needs -- rather than one giant component handling everything, or components split so finely that data has to be threaded awkwardly between them.

It schedules a re-render with the new state value; it does not mutate the existing state variable synchronously in place, and the update may be batched together with other state updates before React actually re-renders.

State updates can be batched, so `count` inside a closure might be stale by the time an update actually applies. The functional form receives the true latest value at update time, avoiding lost updates when multiple updates are scheduled close together.

Common mistake: Calling setCount(count + 1) multiple times in the same handler expecting each call to add one, when they all read the same stale `count` closure value.

React compares state by reference to decide whether to re-render; mutating the existing array in place doesn't create a new reference, so React may not detect the change and skip re-rendering.

A controlled input's value is driven entirely by React state (`value={state}` + `onChange`); an uncontrolled input manages its own value internally in the DOM, read via a ref only when needed rather than tracked in state on every keystroke.

A cross-browser wrapper object around the native DOM event that React passes to event handlers, normalizing behavior across browsers while still exposing the underlying native event when needed.

When two or more sibling components need to share or stay synchronized on the same piece of state -- lifting it to their nearest common ancestor and passing it down (with a callback to update it) keeps a single source of truth instead of duplicated, potentially inconsistent local state.

Storing a value in state that could instead be computed from existing state/props on every render risks the two falling out of sync and adds unnecessary re-render triggers -- deriving it during render keeps a single source of truth.

Both can render conditionally, but `&&` short-circuit rendering has a known pitfall: if the left side evaluates to `0` (a falsy but renderable number) rather than `false`, React renders the literal `0` on the page instead of nothing.

Common mistake: Writing `{count && <Badge count={count} />}`, which renders a stray "0" on the page when count is 0.

The parent passes a callback function down as a prop; the child calls that function (often with an argument) when something happens, letting the parent update its own state in response -- data itself still only flows down through props.

Loading, error, empty (successfully loaded but no data), and success/populated -- a component that only handles the success case will show a confusing blank or broken UI in the other three situations.

Synchronizing a component with something outside React's own rendering -- e.g. fetching data, subscribing to an external event source, or manually manipulating a DOM node not managed by React.

It tells React when to re-run the effect: an empty array (`[]`) means run once after the first render only; omitting the array means run after every render; a list of values means re-run whenever any of those values changes between renders.

An optional function returned from the effect callback; React runs it before the effect re-runs on a later render, and once more when the component unmounts -- used to cancel subscriptions, timers, or in-flight requests started by the effect.

If the effect re-runs (e.g. an id prop changes) before a previous fetch finishes, the older, now-stale response could resolve after the newer one and incorrectly overwrite it. It's typically avoided with a cleanup flag or an `AbortController` that ignores/cancels the outdated request.

useEffect(() => {
  let cancelled = false;
  fetchUser(id).then((data) => {
    if (!cancelled) setUser(data);
  });
  return () => {
    cancelled = true;
  };
}, [id]);

Common mistake: Fetching data on prop change without a cancellation guard, so a slow earlier request can overwrite a faster, more recent one.

Rendering must stay a pure, predictable calculation of UI from state/props -- triggering a network request as a side effect of render can fire duplicate requests on every re-render and makes the component's behavior unpredictable; side effects belong in `useEffect` (or an event handler) instead.

A new object/array literal (e.g. `{ id }`) is a different reference on every render, even with identical contents -- putting it directly in the dependency array causes the effect to re-run on every render, defeating the purpose of the dependency array.

Common mistake: Passing a freshly-created object or array literal as a dependency, causing the effect to re-run on every render regardless of the actual data.

A reusable function that itself calls other hooks (`useState`, `useEffect`, etc.) to encapsulate reusable stateful logic across components -- its name must start with `use` so React's linter and runtime rules-of-hooks checks can recognize it as a hook.

Hooks must only be called at the top level of a component or custom hook (never inside loops, conditions, or nested functions), because React tracks each hook's state by the order it was called in during render -- conditionally skipping a hook call shifts that order and corrupts state tracking for subsequent hooks.

`useEffect` runs asynchronously after the browser has painted the screen; `useLayoutEffect` runs synchronously after DOM mutations but before the browser paints, useful when you need to measure or adjust the DOM before the user sees a visual flicker.

It keeps a component self-sufficient and re-usable, and lets it automatically refetch when the relevant dependency (like an id) changes, without requiring the parent to know about or coordinate every child's data needs.

Context lets you share a value across a component tree without manually threading it through every intermediate component's props -- appropriate for genuinely global-ish data (theme, current user, locale). It should be avoided for state that only a couple of nearby components need, where prop passing or composition is simpler and keeps components more independently testable.

Every component consuming a Context re-renders whenever the Context's value changes, even if that component only cares about part of the value -- putting fast-changing data in a broad Context can cause much more re-rendering than passing that specific data as a targeted prop.

It skips a component's re-render if its props are shallowly equal to the previous render's props. It's worth applying to components that render often with unchanged props and are expensive to re-render -- applying it everywhere by default adds comparison overhead without necessarily helping.

`useMemo` memoizes a computed value between renders (recomputing only when its dependencies change); `useCallback` memoizes a function reference itself (returning the same function identity across renders unless dependencies change) -- `useCallback(fn, deps)` is roughly equivalent to `useMemo(() => fn, deps)`.

A component (implemented with a class component's `componentDidCatch`/`getDerivedStateFromError`, or a library helper) that catches rendering errors in its child tree and shows a fallback UI instead of crashing the whole app. It does not catch errors in event handlers, async code, or errors thrown during server rendering outside its own render.

Keyboard and screen-reader users rely on semantic elements (`<button>`, `<label>`, headings in order) and visible focus indicators to navigate and understand the page -- a clickable `<div>` with no semantic role or focus handling is invisible to assistive technology and unusable via keyboard alone.

Common mistake: Building an interactive control as a styled <div onClick> instead of a real <button>, making it unreachable and unusable by keyboard and screen-reader users.

Tests that query the rendered DOM by visible text/roles and simulate real user interactions stay valid even if a component's internal implementation (state shape, hooks used) is refactored -- tests that reach into internal state or instance methods break on refactors that don't actually change user-facing behavior.

The virtual DOM is React's lightweight in-memory representation of the UI tree; reconciliation is the process of comparing (diffing) the new virtual DOM tree against the previous one to compute the minimal set of real DOM updates needed, rather than re-rendering the entire page.

It couples unrelated components to data-fetching concerns they don't otherwise need, makes each intermediate component harder to reuse or test in isolation, and often means a small UI change requires threading new props through several layers that shouldn't need to know about it.

Which component(s) actually need this state to render correctly, and is it the single source of truth or does it duplicate/derive from state that already exists elsewhere -- state should generally live in the lowest common ancestor of every component that reads or writes it, and nowhere higher than necessary.

`children` is the special prop containing whatever JSX is nested between a component's opening and closing tags -- a component like `<Card>{...}</Card>` can render a consistent wrapper around arbitrary content without knowing what that content is in advance.

An HOC is a function that takes a component and returns a new, enhanced component (e.g. `withAuth(Component)`). Custom hooks generally achieve the same reuse of stateful logic with less indirection (no wrapper component, no prop-name collisions), which is why hooks are now the more common pattern.

It lets you code-split a component into a separate bundle chunk, loaded only when that component is actually rendered -- typically paired with `<Suspense>` to show a fallback while the chunk downloads, reducing the app's initial bundle size.

`createPortal` renders a component's output into a DOM node outside its normal parent hierarchy in the tree, while it still behaves as a child in React's component tree (for context, event bubbling) -- commonly used for modals/tooltips that need to escape a parent's `overflow: hidden` or `z-index` stacking context.

The router intercepts navigation, updates the browser's URL via the History API, and swaps which components are rendered based on the current path -- all without the browser issuing a new full-page request to the server.

Splitting separates two different concerns (data-fetching logic and rendering logic) that change for different reasons -- the presentational half can be tested and reused with mock data alone, without needing to mock network calls just to verify rendering.

CSR ships a mostly-empty HTML shell and renders everything in the browser via JavaScript after it loads; SSR renders the initial HTML on the server per request, so the browser receives already-populated markup, generally improving perceived load time and SEO before client-side JavaScript takes over ('hydrates') the page.

The process where React attaches event listeners and internal state to the already-rendered server HTML in the browser, making the static markup interactive, without re-rendering the DOM from scratch if the server and client output match.

React only reads `key` on the direct children of the element performing the mapping/reconciliation for that list -- putting it deeper inside each list item's own children has no effect on how React tracks and diffs the list items themselves.

A narrow, well-considered prop interface keeps a component's responsibilities clear and prevents callers from coupling to internal implementation details it wasn't designed to expose -- an overly permissive interface (e.g. accepting a raw style object or an arbitrary render callback for everything) tends to make future refactors riskier.