In React, what is the difference between calling useEffect(fn) with no second argument, useEffect(fn, []), and useEffect(fn, [a, b])?

## The three shapes `useEffect` takes a function and an optional array. The array is the only thing that varies, and it produces three distinct cadences. ```js useEffect(() => { /* after EVERY render */ }); useEffect(() => { /* after the first render only */ }, []); useEffect(() => { /* after the first render, and whenever a or b changes */ }, [a, b]); ``` All three run *after* React has committed the render and the browser has painted. The array does not change when the effect runs relative to painting; it changes how often React decides the effect needs to run at all. ## No array: run after every render Without a second argument, React has no information about what the effect reads, so it re-synchronizes after every render — including renders caused by a parent re-rendering with identical props. This is always *correct* (the body always sees the newest values) and often wasteful. It is also the classic infinite-loop shape: if the effect calls a state setter with a new value, that render triggers the effect, which triggers a render, forever. ## Empty array: a claim, not a switch `[]` is frequently described as "run once on mount". That is what it *does*, but reading it as a switch is what produces bugs. What you are actually asserting is: *nothing this effect reads is reactive*. React takes you at your word and never re-runs the body, so the function keeps the props and state values it captured during the first render, forever. If the body reads `count`, `userId`, or a prop, those values are frozen at their first-render values and the effect silently operates on stale data. When the claim is true — attaching a listener to `window`, starting a one-time imperative setup — `[]` is exactly right. ## A list of dependencies: positional Object.is With `[a, b]`, React stores the array from the previous run and compares it entry by entry using `Object.is` — the same comparison React uses to decide whether state actually changed. Two consequences follow. First, the comparison is by identity for objects, arrays and functions: a value that is *structurally* the same but freshly created counts as changed. Second, the comparison is positional, so the array must have the same length and the same order on every render. Writing a dependency array whose contents depend on a condition breaks that: ```js // wrong: the array's size changes between renders useEffect(() => { /* ... */ }, isAdmin ? [userId, role] : [userId]); ``` In development React warns that the final argument changed size between renders and that the order and size must remain constant. The array should be a literal with a fixed shape. ## Cleanup cadence follows the array The function you return is not "the unmount handler"; it is "undo the last run". React runs it before each re-run of the effect and once more at unmount. So the cadence of cleanup is exactly the cadence of the array: every render with no array, before each change with a dependency list, only at unmount with `[]`. A subscription started in an effect with `[roomId]` is torn down and re-established each time `roomId` changes, which is usually precisely what you want. ## Choosing between them You do not really choose. You write the effect body, then list every reactive value it reads — props, state, and anything derived from them inside the component — and the array falls out of that. The `react-hooks/exhaustive-deps` lint rule computes the same list mechanically. If the resulting array causes the effect to run more often than you want, the fix is to change the *code* (move a value inside the effect, use a functional state updater, stabilize an identity with `useMemo` or `useCallback`) rather than to trim the array. Trimming the array does not make the dependency go away; it only hides it from React. ## What an interviewer is listening for The weak answer treats the array as an optimization: "pass `[]` so it doesn't run so much." The strong answer describes it as a declaration of what the effect is synchronized with, notes `Object.is` and positional comparison, and can state precisely what breaks when the declaration is a lie — the body keeps running against values captured at an earlier render.