To stop an effect re-running every render, a React codebase writes `useEffect(() => { load(filters); }, [JSON.stringify(filters)]);`, where `filters` is an object rebuilt in the component body each render. When does that work, when does it fail, and what would you do instead?

## What the trick is actually doing React compares dependency entries with `Object.is`. Objects fail that comparison whenever they are rebuilt, so the workaround replaces the object with a *string derived from* the object: strings compare by value, so an unchanged object yields an unchanged dependency and the effect settles. As a mental model it is "structural equality, cheaply". The question is whether `JSON.stringify` is a sound structural-equality function. It is not — it is a serializer with a defined set of lossy behaviours. ## Where it silently over-fires `JSON.stringify` does not sort keys; it walks own enumerable string-keyed properties in the object's own order. Two objects a user would call identical serialize differently when the code paths that built them inserted keys in a different order: ```js JSON.stringify({ status: 'open', sort: 'asc' }); // {"status":"open","sort":"asc"} JSON.stringify({ sort: 'asc', status: 'open' }); // {"sort":"asc","status":"open"} ``` The strings differ, so the effect re-runs — the exact churn the trick was meant to stop, now hidden behind code that looks like it solved the problem. ## Where it silently under-fires — the dangerous half Serialization is lossy, and the losses collapse distinct objects into one string: - Properties whose value is `undefined` are omitted, as are function-valued and symbol-valued properties. `{ q: 'a' }` and `{ q: 'a', cursor: undefined }` both serialize to `{"q":"a"}`. - `Map` and `Set` have no JSON representation and serialize as `{}`, so two different Sets look identical. - `Date` is serialized through `toJSON` to an ISO string, which is usually fine but loses the object identity distinction. - `NaN` and `Infinity` serialize as `null`, flattening distinct numeric states. - Circular references throw a `TypeError`, turning a render into a crash — and it will be the production data shape that finds it, not your fixture. An over-firing effect is a performance bug you can see. An under-firing effect is a correctness bug that shows as stale data, and it is far more expensive to diagnose. ## The costs you also inherit The call runs on every render, walking the whole object graph, so cost scales with payload size on the hot path. And because the dependency array now contains an expression rather than a value, `react-hooks/exhaustive-deps` cannot statically relate it to what the effect reads — it reports the complex expression and asks you to extract it to a variable, which means you have also given up the rule's protection against a genuinely missing dependency. ## What to do instead, in order of preference **1. Depend on primitives.** If the object is built in the body from `status`, `sort` and `page`, list those directly and construct the object inside the callback. Primitives compare by value, the dependency list documents the real inputs, and the lint rule keeps working. ```jsx useEffect(() => { load({ status, sort, page }); }, [status, sort, page]); ``` **2. Stabilize at the creation site.** If the object arrives as a prop or from a hook, fix it where it is made — hoist it if invariant, `useMemo` it against primitive dependencies if derived, or flatten it into primitive props so no identity contract exists. **3. Build a deliberate key, not a blanket serialization.** When the input really is variable-shaped, derive a small key from fields you control, in a fixed order, and hoist it to a named variable so the dependency array stays statically analysable: ```jsx const tagKey = tags.join(','); useEffect(() => { load({ status, tags: tagKey.split(',') }); }, [status, tagKey]); ``` This is honest about being a key: you chose the fields, the order and the cost, and a reader can see the assumption. **4. A deep-compare guard, sparingly.** Keeping the previous value in a `useRef` and replacing it only when a deep comparison says it changed gives correct structural semantics, but it adds a comparison on every render and a helper to maintain. It is a last resort for genuinely dynamic shapes, not a default. ## How to answer the reviewer The short version: `JSON.stringify` in a dependency array is not wrong because it is ugly, it is wrong because it silently answers a different question than the one asked. Fix identity where identity is created; use a serialized key only when you have deliberately chosen the fields and can state what it ignores.