React Interview Questions & Answers

Props flow one-way, from parent to child, and a component should never modify its own props -- if it needs different data, the parent passes new props. State is local to a component (or lifted up to a shared ancestor) and is updated via setState/useState, which schedules a re-render with the new value. A component can be purely presentational, driven entirely by props, or stateful, managing its own internal data.

`const [count, setCount] = useState(0)` gives you a value and a setter that triggers a re-render when called. `useEffect(() => { fetchData(); }, [id])` runs the fetch after the component mounts and again whenever `id` changes, because it's listed in the dependency array. An empty dependency array (`[]`) means the effect runs only once, on mount; omitting the array entirely means it runs after every render.

Always include every value the effect reads from component scope in the dependency array (or use a linter rule like exhaustive-deps) to avoid stale closures.

Omitting a value from useEffect's dependency array to 'stop it from re-running,' which causes the effect to silently use a stale, captured version of that value instead.

Because JSX is just JavaScript, you can write `{isLoggedIn ? : }` for either/or rendering, `{items.length > 0 && }` to render something only when a condition is true, or return early from the component function entirely (`if (loading) return ;`) before the main render output.

Be careful with && for numeric conditions -- `{count && }` renders a literal 0 on the page when count is 0, since 0 is falsy but still gets rendered as text; use `{count > 0 && ...}` instead.

Writing `{count && }` and seeing a stray '0' rendered on the page when count is zero.

A typical pattern: `const [data, setData] = useState(null); const [loading, setLoading] = useState(true); const [error, setError] = useState(null);` then inside `useEffect`, call the API, and set data/loading/error accordingly, including in a try/catch so failures update the error state instead of throwing unhandled. Cleanup (e.g. an AbortController) matters if the component can unmount or the dependency can change before the request finishes.

Guard against setting state after the component has unmounted (a stale request completing late) by using a cleanup function or an AbortController.

Fetching data without a cleanup/cancellation mechanism, causing a 'setState on an unmounted component' warning or, worse, a stale response overwriting newer data.

Browsers don't understand JSX natively -- `` is compiled into something like `React.createElement('div', {className: 'card'}, title)`, which returns a plain JavaScript object describing that element. This is why JSX requires a build step (Babel, or a bundler with a JSX transform) and why you can embed any JavaScript expression inside curly braces -- it's ultimately just function calls, not a templating language with its own separate rules.

Directly manipulating the browser DOM is comparatively slow, especially with frequent updates. React keeps a lightweight virtual representation of the UI tree, and whenever state changes, it builds a new virtual tree, diffs it against the previous one (reconciliation), and applies only the actual changes to the real DOM in a batched update -- avoiding unnecessary, expensive re-renders of unaffected elements.

Before hooks, stateful logic required class components with lifecycle methods (componentDidMount, componentDidUpdate, etc.), and reusing stateful logic across components meant patterns like higher-order components or render props, which added wrapper layers and made component trees harder to follow. Hooks like useState, useEffect, and custom hooks let you extract and reuse stateful logic directly as functions, keeping components flatter and logic more composable.

Calling hooks conditionally or inside loops, which breaks React's assumption that hooks are called in the same order on every render.

With a controlled input, every keystroke updates state via onChange, and the input's displayed value always comes from that state -- giving React full visibility and control over the form data at all times. An uncontrolled input just lets the browser manage its own value internally, and you read it on demand with a ref (e.g. on form submit), which is simpler for basic cases but harder to validate or react to in real time.

Use controlled components when you need real-time validation, conditional rendering based on input, or to synchronize the value elsewhere; uncontrolled components are fine for simple, one-shot forms.

Prop drilling means passing a prop down through several layers of components that don't themselves use it, just to get it to a deeply nested child. Context (createContext + a Provider) lets any descendant read the value directly via useContext, skipping the intermediate layers. It's well suited to genuinely global, rarely-changing data; for frequently-changing state shared across many components, a dedicated state management library often scales better, since every context consumer re-renders on any context value change.

Split contexts by concern (e.g. separate ThemeContext and AuthContext) rather than one giant context object, so unrelated consumers don't re-render on unrelated changes.

Putting frequently-changing state (like every keystroke of a search box) into a single broad context that many components consume, causing widespread unnecessary re-renders.

useState is simplest for independent, simple values. useReducer is a better fit when several pieces of state update together in response to the same action, when the next state depends heavily on the previous state in non-trivial ways, or when you want the update logic testable in isolation from the component (a pure reducer function is easy to unit test without rendering anything).

Instead of the browser requesting a new HTML document from the server on every link click, React Router listens for navigation, prevents the default full-page reload, updates the URL via the History API, and re-renders whichever route component matches the new path -- all within the same loaded page. This gives an app-like feel (instant transitions) but means you need to handle things like scroll restoration, code-splitting per route, and SEO (since content is rendered client-side) deliberately.

A Server Component can, for example, query a database directly during server rendering and never ships its own logic to the browser, shrinking the client bundle and improving initial load. Client Components are still needed for anything interactive (state, effects, event handlers) and are marked explicitly (e.g. a 'use client' directive in frameworks that support this model). The two compose together: Server Components can render Client Components as children, but not the other way around directly.

React Testing Library encourages querying the rendered output the way a user would (by visible text, label, or role) and firing real events (clicks, typing) rather than reaching into component internals or state directly. This makes tests resilient to refactors that don't change user-visible behavior, and catches regressions that actually matter to users.

Test behavior and output, not implementation detail (e.g. don't assert on a component's internal state variable directly; assert on what's rendered).

Writing tests that assert on internal state or call internal methods directly, which breaks on harmless refactors and doesn't actually verify user-facing behavior.

When element types differ (e.g. a

Best Practices

Common Mistakes