The Context Selector Pattern

The plain-language idea

The context lesson already covers the core limitation: a Provider's consumers all re-render when the provided value changes, even if a given consumer only reads one field of it. Splitting into several narrower contexts helps, but sometimes you have one genuinely related bundle of state (a big form, a canvas editor's selection state) where splitting it into ten separate contexts is its own kind of mess.

The selector pattern solves it differently: instead of subscribing to the whole value, a consumer passes a selector function and only re-renders when the piece that function returns actually changes. React's built-in Context doesn't support this natively — but you can build it on top of useSyncExternalStore, which is exactly what libraries like use-context-selector and zustand's context bindings do under the hood.

See it in a real thing: a minimal selector context

function createSelectorContext() {
  const StoreContext = createContext(null);

  function Provider({ value, children }) {
    const listeners = useRef(new Set()).current;
    const valueRef = useRef(value);
    valueRef.current = value;

    // Notify subscribers after every render where `value` changed identity.
    useEffect(() => {
      listeners.forEach((listener) => listener());
    });

    const store = useRef({
      getSnapshot: () => valueRef.current,
      subscribe: (listener) => {
        listeners.add(listener);
        return () => listeners.delete(listener);
      },
    }).current;

    return <StoreContext.Provider value={store}>{children}</StoreContext.Provider>;
  }

  function useSelector(selector) {
    const store = useContext(StoreContext);
    return useSyncExternalStore(store.subscribe, () => selector(store.getSnapshot()));
  }

  return { Provider, useSelector };
}

const UserContext = createSelectorContext();

function App() {
  const [user, setUser] = useState({ name: "Adesh", theme: "dark" });
  return (
    <UserContext.Provider value={user}>
      <NameBadge />
      <ThemeToggle onToggle={() => setUser((u) => ({ ...u, theme: u.theme === "dark" ? "light" : "dark" }))} />
    </UserContext.Provider>
  );
}

function NameBadge() {
  const name = UserContext.useSelector((u) => u.name);
  return <span>{name}</span>; // never re-renders when only `theme` changes
}

The trick is useSyncExternalStore: on every notification it calls getSnapshot again, but it only triggers a re-render if the returned value differs from last time (Object.is comparison). Since getSnapshot here is selector(store.getSnapshot()), NameBadge only re-renders when u.name itself changes — a theme update produces a new name snapshot that's Object.is-equal to the old one, so React bails out.

What people usually miss

Watch out

• The selector must return something with stable identity for unchanged data. If your selector does (u) => ({ name: u.name }), it returns a new object every call and Object.is never matches — you've silently defeated the whole pattern. Select primitives or already-stable references.
• This isn't a replacement for splitting contexts when the split is natural. If your value cleanly separates into "state that changes often" and "state that changes rarely," two contexts are simpler and need no custom hook at all.
• useSyncExternalStore's snapshot function must be cheap and pure. It can run on every render just to check for changes, not only on actual updates — an expensive selector here is a real performance cost, not a free lookup.

The genealogy: it's the context lesson's re-render cost, solved

This is a direct answer to the re-render problem the context lesson describes — instead of avoiding it by re-architecting into multiple providers, it avoids it by changing what "subscribing" means for a single provider. Underneath, it's the same external-store subscription model React itself uses to read the browser's own state (window size, online status) safely.