A React component calls useEffect(() => { load(options); }, [options]) where const options = { page } is built in the component body. The effect re-runs on every render even when page never changes. Why?

## What the dependency check actually is Every time a component renders, React compares the dependency array you just passed with the one it stored from the previous render for that hook slot. The comparison is positional and per item, and the predicate is `Object.is`. For primitives that behaves like `===` with two refinements — `NaN` equals `NaN`, and `+0` does not equal `-0`. For objects, arrays and functions it is pure reference identity: two values are the same only when they are literally the same object in memory. There is no deep comparison anywhere in this path. React never walks the object's properties, and it never inspects the effect body to work out what you meant. ## Why the object dependency always differs A component body runs top to bottom on every render. That means this line runs again each time: ```js const options = { page }; ``` The object literal is an expression, so it allocates a fresh object per render. `page` may be `3` on ten consecutive renders and the ten `options` objects will still be ten distinct references. `Object.is` compares them pairwise and returns `false` every time, so React tears down and re-runs the effect on every commit — the same behaviour as if you had omitted the dependency array entirely. The failure mode escalates fast when the effect writes state. Render creates a new `options`, the dependency check fails, the effect runs, `load` resolves and sets state, the state change triggers a render, which creates a new `options`… That is the classic infinite-request loop, and its root cause is identity, not the fetching. ## The same trap in three disguises Anything constructed during render has this property: ```js useEffect(fn, [{ page }]); // new object each render useEffect(fn, [items.filter(Boolean)]); // new array each render useEffect(fn, [() => save(id)]); // new function each render useEffect(fn, [style]); // new object, if style is built inline ``` An inline arrow is the most commonly missed one, because it does not look like data. A callback prop received from a parent that builds it inline has exactly the same problem — the identity changes in the parent, and your dependency array faithfully reports the change. ## Fix one: depend on the primitives The strongest fix is usually to stop depending on the wrapper: ```js useEffect(() => { load({ page }); }, [page]); ``` The object is now built inside the effect, where its identity is irrelevant, and the dependency is a number that compares by value. This is worth internalising as a habit: **prefer primitive dependencies**. They compare correctly for free and they say exactly what the effect reacts to. ## Fix two: hoist what is constant If the object does not depend on anything from the render, move it out of the component entirely: ```js const DEFAULT_OPTIONS = { retries: 3 }; function Widget() { useEffect(() => load(DEFAULT_OPTIONS), []); } ``` A module-level constant has one identity for the process lifetime, so it can never destabilise a dependency array. ## Fix three: stabilise the identity deliberately When something genuinely needs the object — you pass it onward, or it is expensive to construct — give it a stable identity with `useMemo` keyed on the primitives it derives from, and then depend on the memoized value. That is a real tool, but treat it as the third choice: it adds a second dependency array you now have to keep honest, and it moves the problem rather than removing it. ## Why React chose identity over deep equality Deep comparison would have to run on every render for every dependency, its cost would scale with the data rather than the number of dependencies, and it would still be wrong for functions. Identity is O(1), predictable, and matches how JavaScript itself defines sameness. The tradeoff React makes is that keeping dependencies comparable is the author's job — which is exactly what this question is testing. ## Diagnosing it in the wild The tell is an effect that runs far more often than the data changes, usually noticed as repeated network calls or a log line that never stops. Log the dependency alongside a render counter, or compare identities directly: if `Object.is` on consecutive values of a dependency is `false` while the rendered output looks unchanged, you have found it.