Common React Pitfalls

Most React bugs come from a small set of recurring mistakes rather than exotic edge cases. Mutating state directly, misusing the useEffect dependency array, using unstable list keys, and calling hooks conditionally are patterns that work 'most of the time' in a demo but break in subtle ways under real-world conditions like re-renders, list reordering, or fast user interaction. Recognizing these pitfalls — and knowing precisely why each one is wrong, not just that it's discouraged — is one of the fastest ways to level up as a React developer and is a favorite area for interviewers to probe.

React decides whether to re-render by comparing the previous and next state references, typically with Object.is. If you mutate an array or object in place (state.items.push(newItem)) and then call setState(state), the reference is unchanged, so React sees the 'same' object and may skip the re-render entirely, or worse, update the DOM inconsistently since some optimizations assume immutability. The fix is to always create a new array or object — setItems([...items, newItem]) or setState({ ...state, key: value }) — so React can detect the change via reference comparison and correctly schedule a re-render.

When an effect reads a variable, like a piece of state or a prop, but that variable isn't listed in the dependency array, the effect's closure captures the value from whichever render it was created in and never sees updates to it — this is the classic 'stale closure' bug. For example, an interval callback that reads a count state variable but has an empty dependency array will keep incrementing from the same stale count value forever instead of the current one. The fix is either to include every reactive value the effect reads in the dependency array, or to restructure the code — for instance using the functional updater form setCount(c => c + 1) — so the effect no longer needs that value as a dependency.

Index-based keys tie a list item's identity to its position rather than its actual data, so if items are reordered, inserted, or removed, React can incorrectly match old elements (and their component state, like open/closed toggles or input values) to different underlying data than before. A common symptom is a text input in a to-do list retaining the wrong text after an earlier item is deleted, because React reused the DOM node at that index for a different todo. The fix is to key list items by a stable, unique identifier from the data itself, such as a database id or a generated UUID, so identity survives reordering.

Every time a parent component renders, an inline object literal (style={{ color: 'red' }}) or arrow function (onClick={() => doThing(id)}) passed as a prop creates a brand-new reference, even if its contents are identical to the last render. If the child component is wrapped in React.memo to skip re-renders when props are unchanged, that optimization is defeated because the shallow prop comparison sees a new object/function reference every time and re-renders anyway. The fix is to memoize the value with useMemo for objects or useCallback for functions when passing them to a memoized child, or to move static objects outside the component entirely so the reference never changes.

Effects that set up a subscription, event listener, interval, or timeout need to tear that resource down when the component unmounts or before the effect re-runs, by returning a cleanup function from useEffect. Without cleanup, the subscription or timer keeps running after the component is gone, which can cause memory leaks, duplicated event listeners piling up on every re-run, or a 'setState on an unmounted component' warning when the stale callback eventually fires and tries to update state that no longer exists. The fix is to always return a cleanup function — return () => clearInterval(id) or return () => subscription.unsubscribe() — that mirrors whatever setup the effect performed.

React identifies each hook call by its position in the sequence of hook calls during a render, not by name, so it depends on that sequence being identical on every render for a given component. If a hook is called only when some condition is true, the total number and order of hook calls can differ between renders, causing React to associate the wrong stored state or effect with the wrong hook call — a bug that often manifests as state 'bleeding' between unrelated pieces of data or as a hard runtime error. The fix is to always call the hook unconditionally at the top level and instead put the conditional logic inside the hook, such as useEffect(() => { if (condition) { ... } }, [condition]).

Calling a fetch or other side-effecting operation directly during render means it runs on every single render, including re-renders triggered by unrelated state changes, and it runs during the render phase itself which React expects to be pure and free of side effects. This can trigger infinite loops if the fetch's response updates state, which triggers a re-render, which triggers the fetch again. The fix is to perform data fetching inside useEffect with an appropriate dependency array so it runs only when the relevant inputs actually change, and to handle race conditions (e.g., a fast-changing search query) with cleanup logic that ignores stale responses.

Props are meant to be treated as read-only inputs owned by the parent; mutating a prop object or array inside a child silently changes data the parent still believes is unchanged, since the parent's reference points to the same mutated object. This breaks React's reference-equality assumptions the same way direct state mutation does, and it can produce inconsistent behavior where the UI doesn't reflect the actual current data, or where the parent's own re-render logic misses the change because the reference never changed. The fix is for a child that needs to modify data to call a callback function passed down as a prop so the parent can update its own state immutably, keeping the one-way data flow intact.