In React, what does useMemo actually guarantee about the value it returns between renders, and what must the factory you pass it never do?

## What the contract actually says The useful mental model is: *while the dependencies compare equal, `useMemo` will probably give you the same value back — and you are not allowed to depend on "probably".* React's own documentation frames the hook as a performance optimization, not a semantic guarantee. That single sentence decides how you are permitted to write the surrounding code. The practical rule that follows is a test you can apply to any `useMemo` call: **if the factory ran on every render, would the component still be correct?** If yes, the hook is being used as intended and only speed changes. If no — if losing the cache would open a second connection, register a duplicate, reset something, or produce a visibly different UI — you have written a correctness dependency on a cache, and it is a bug waiting for the day React drops it. ## Why the cache can be dropped React keeps the cached value on the component's internal work structures, and it treats that memory as reclaimable. It has historically reserved the right to discard cached values in situations such as freeing memory for content that is not visible. You do not get to know when this happens, there is no callback when it does, and it is not something you can observe reliably in development to "prove" it never occurs. The guarantee you can rely on is the negative one: a change in dependencies definitely re-runs the factory. The positive direction — unchanged dependencies definitely reuse the value — is best effort. The cache is also strictly per component instance and per call site. Unmounting the component discards it along with the rest of that instance's state; remounting starts from nothing and calls the factory again. ## Purity: the factory runs during render `useMemo`'s factory is called synchronously in the middle of rendering, before your component returns its output. Rendering in React must be pure, which means the factory inherits the same restriction. Concretely, do not: - start a fetch, open a socket, or subscribe to anything; - mutate the DOM, or read layout in order to write it back; - assign to a ref (`ref.current = ...`) or to a module-level variable; - call a state setter, including "just to sync some derived state"; - mutate an object or array received via props or state. All of those are observable effects, and React may render a component whose output it then throws away, or render at a moment that has nothing to do with what the user just did. An effect performed there happens at an unpredictable time and possibly for a render that never reaches the screen. What *is* fine is pure computation over values already in scope: filtering, sorting a copy, deriving a shape, building a lookup map, constructing a plain object you want to keep referentially stable. ```js // fine - pure derivation over a copy const visible = useMemo( () => rows.filter((r) => r.active).sort((a, b) => a.rank - b.rank), [rows] ); // wrong - a side effect during render const data = useMemo(() => fetch(url).then((r) => r.json()), [url]); ``` Note the second example is wrong twice over: it performs I/O during render, and it would be re-issued whenever the cache is dropped. ## What breaks when the guarantee is assumed Three failure shapes recur: 1. **Resource creation.** Building something that owns an external resource inside the factory means a discarded cache silently creates a second one, and nothing ever tears the first one down — there is no cleanup channel on `useMemo`. 2. **Identity as a protocol.** Code that stores the memoized object as a key, or compares it later to decide whether "the same" thing is still in play, will occasionally see a mismatch after a cache drop and take the wrong branch. 3. **Skipping work by identity.** Using the memo's stable reference as the *only* thing preventing an expensive downstream action means the action fires again unexpectedly when the reference changes. Downstream work must be idempotent or guarded on its own terms. ## The same applies to useCallback `useCallback` is the same cache with a different argument shape, so it carries exactly the same caveat: React may give you a new function identity even when your dependency list did not change. Any code that would malfunction if a callback's identity changed unexpectedly — as opposed to merely doing more work — is relying on a guarantee that does not exist. ## First render, and the cost side On mount the factory always runs; the hook can only save work from the second render onward. And the hook is never free: React stores the dependency array, walks it on every render, and keeps the value alive. That cost is the reason the "is this correct without the cache?" test matters — you should be able to delete a `useMemo` and get a slower but still correct component.