The hook stores the value in a ref and updates it inside useEffect, which runs AFTER the render commits. That ordering is the whole trick: during render, ref.current still holds the value from the previous commit, so the component sees the prior value while React holds the new one. On the very first render the ref is undefined, which usually models the initial state correctly. This is the textbook implementation and the one most React projects copy-paste.

Often you do not actually need the previous value, just whether it changed. useChanged builds on usePrevious and returns a boolean, which keeps call sites concise (if (useChanged(userId)) { ... }). The first render returns true because previous is undefined, which usually matches the desired behaviour: treat 'first time you see a value' as a change. If you want the first render to count as unchanged, special-case it with a second ref that flips after the first commit.

When you need more than just the last value (an undo stack, a velocity calculation, a streak detector), keeping the last size values in a ring is straightforward. The ref-plus-effect pattern keeps the history off the React tree so updates do not trigger extra renders. The slice(-size) cap keeps memory bounded while preserving insertion order. Because useEffect runs after commit, callers see history that excludes the current value during the first render after a change, which is the intuitive behaviour for diff-style logic.