You are publishing a shared custom hook, useFilters(), that returns the current filter state plus functions to change it. Consumers memoize child components and list your functions in dependency arrays. What identity guarantees should the hook's return value make, and how do you implement them?

## Why identity is part of a hook's public contract When a hook is used in one component you control, function identity is a detail. When it is a shared hook, every value it returns can end up in three places you do not control: a dependency array, a `React.memo` child's props, and a `useMemo` input. In all three, identity decides behaviour. So the honest API of `useFilters()` is not just "returns filters and setters" — it is "returns filters, which change identity when the filters change, and `setOne`/`clear`, which never change identity". Consumers cannot discover that by reading types, so it belongs in the hook's documentation and in your tests. ## What React already guarantees Two things are stable without any work on your part: the setter returned by `useState` and the `dispatch` returned by `useReducer`. React documents both, which is why `dispatch` is safe to pass through context and to omit from dependency arrays. If your hook's public surface can be the raw `dispatch`, you are done. Note what is *not* stable: the array `useState` returns is a fresh array each render, refs are stable objects but `ref.current` is not a value React tracks, and anything you build in the hook body is new on every render unless you memoize it. ## Making your own callbacks stable The usual mistake is reaching for `useCallback` and then listing current state in its dependencies: ```javascript // Unstable: identity changes whenever `filters` changes — i.e. constantly. const setOne = useCallback((key, value) => { setFilters({ ...filters, [key]: value }); }, [filters]); ``` This is `useCallback` in name only. The fix is not to shorten the dependency list but to remove the need for the dependency: ```javascript // Stable: the updater form receives the previous value, so no dependency is needed. const setOne = useCallback((key, value) => { setFilters((prev) => ({ ...prev, [key]: value })); }, []); ``` The updater form covers most cases, because most callbacks are computing the next state from the previous one. When a callback needs the latest value for something else — logging it, sending it to an API, deciding whether to act — use a ref as a mailbox for the current value and read it inside a stable callback: ```javascript const filtersRef = useRef(filters); useEffect(() => { filtersRef.current = filters; }); const submit = useCallback(() => { api.search(filtersRef.current); // always the latest, no dependency }, []); ``` The trade-off is deliberate: `submit` is no longer reactive to `filters`, which is exactly what you want for an imperative action and exactly what you do not want for something that should re-run when filters change. ## Honest identity for data Stability cuts both ways. A hook that returns a new object for unchanged data defeats every consumer's memoization; a hook that returns a stale object for changed data causes missed renders and is much worse. So do not "stabilise" data by caching it past a real change. Where a returned value is derived — a filtered list, a computed summary — wrap the derivation in `useMemo` keyed on the real inputs, so its identity changes exactly when the underlying data does. The returned container object itself is a lesser concern. `return { filters, setOne, clear }` creates a fresh object each render, which costs nothing as long as consumers destructure it immediately. It only matters if someone forwards the whole object as a prop to a memoized child. Memoizing the container is cheap insurance for a widely-used hook; telling callers to pass individual fields is the better guidance. ## Proving and documenting it Stability is a promise that silently breaks. Protect it: write a test that renders the hook, triggers an unrelated state change, and asserts the callback identity is unchanged; document per field what is stable; and be conservative about how much you promise, because every guarantee constrains your implementation forever. Callers who follow the React lint rules will list your callbacks in their dependency arrays whether you like it or not, so an unstable callback in a shared hook shows up as an effect that runs every render somewhere far from your file. That distance is why this belongs in the hook's design, not in the consumer's workaround.