In a React 19 app, code outside the component tree — an HTTP client interceptor, a WebSocket message handler, an analytics module — needs to read and update the current auth token. Why can React Context not serve that, and how would you structure it instead?

## The constraint that decides the design A context value lives in the render tree. `useContext(AuthContext)` and `use(AuthContext)` are hook calls: they execute while React renders a component that sits under the provider, and they resolve to whatever that provider published on its most recent render. React exposes no API that hands the current value of a context to a plain module, and nothing outside the tree can push a new value in — a context value changes only when its provider re-renders. That is a deliberate design, not an oversight. Context is a dependency-injection channel scoped to a tree, and "scoped to a tree" is exactly what an axios interceptor or a socket callback is not. ## Why the obvious workarounds fail **Exporting the context object and reading from it.** The context object is a marker React uses during rendering, not a box holding the value. Reaching for undocumented internals to get at it breaks across versions and gives you the wrong value under concurrent rendering, where different parts of a render pass can be at different points. **Copying the value into a module variable from inside a component.** A `useEffect` that writes `currentToken = token` on every change looks like it works and mostly does — until the non-React code runs before the first commit, or after the component unmounts, or in a second React root. You have created a second copy of the truth that is updated late and never cleaned up. **Passing a setter down through Context to the module.** Now the module holds a callback that only works while a particular provider is mounted, and a stale one after remounts. All three fail for the same reason: React state is being asked to be the source of truth for something that has consumers outside React's lifetime. ## The shape that works: invert the ownership Make a plain module the source of truth. It needs three things — read, write, and subscribe: ```js let token = null; const listeners = new Set(); export const authStore = { getSnapshot: () => token, setToken(next) { token = next; listeners.forEach((l) => l()); }, subscribe(listener) { listeners.add(listener); return () => listeners.delete(listener); }, }; ``` The interceptor and the socket handler now `import { authStore }` and call `authStore.getSnapshot()` or `authStore.setToken(next)` directly. No React, no timing question, no mounted-component precondition. Components bind with `useSyncExternalStore`, which takes the subscribe function and the snapshot getter and returns the current value, re-rendering the component when the store notifies: ```jsx function useToken() { return useSyncExternalStore(authStore.subscribe, authStore.getSnapshot); } ``` Two details matter. `getSnapshot` must return a value that is stable between notifications — a primitive like a token string is safe; returning a freshly built object each call causes React to see a change every time. And on a server render there is no subscription, so a store meant to render on the server supplies a server snapshot as the third argument. ## Where Context still belongs None of this argues against Context — it argues about *what* you publish through it. Publishing the token means only the tree can see it. Publishing the store instance gives you the injection benefits without the constraint: ```jsx <AuthStoreContext value={authStore}>{children}</AuthStoreContext> ``` The value is a stable reference, so the context never causes an update; components pull the instance and subscribe. Tests render a different instance, and a server that must isolate requests creates one store per request instead of relying on a module-level singleton. ## The rule to take away Ask who the consumers are. If every consumer is a component inside one subtree, Context is enough and simplest. The moment a consumer is a module, a callback registered with a browser API, or an interceptor that runs with no component on the stack, the state has left React's jurisdiction — put it in a store and let React subscribe, rather than putting it in React and trying to smuggle it out.