Sharing state with component context

Prop drilling breaks compound components: the children can be nested arbitrarily, so props can’t reach them. The consumer composes the markup, which means you don’t control where Tab and Panel sit in the tree. Any approach that threads activeId through props assumes a fixed shape you don’t have.

// what the consumer writes — note the wrapper div you didn't put there
<Tabs defaultId="a">
  <div className="tab-row">
    <Tab id="a">Account</Tab>
    <Tab id="b">Billing</Tab>
  </div>
  <Panel id="a">…</Panel>
  <Panel id="b">…</Panel>
</Tabs>

Tabs cannot pass a prop to <Tab id="a"> — there’s a <div> in between that Tabs doesn’t render. Props go one level; the active state has to reach an arbitrary depth.

Create a context inside the component’s module — it is the private channel the sub-components share. The createContext call lives next to the component, not in some app-wide providers file. Nothing outside this module imports it. That privacy is the whole point: the consumer composes Tabs and never knows a context exists.

"use client"; // context + state, so this subtree is a Client Component
import { createContext, useContext, useId, useState, useMemo } from "react";

interface TabsCtx { activeId: string; setActiveId: (id: string) => void; }
// not exported — private to this module
const TabsContext = createContext<TabsCtx | null>(null);

// one internal hook the sub-components call; it also enforces "must be inside <Tabs>"
function useTabs() {
  const ctx = useContext(TabsContext);
  if (!ctx) throw new Error("Tab/Panel must be used inside <Tabs>");
  return ctx;
}

TabsContext and useTabs are file-local. The error in useTabs turns a misuse (<Tab> rendered outside <Tabs>) into a clear message instead of a confusing null.

The parent owns the state and provides it; sub-components read the active value with no props passed to them. Tabs holds activeId in useState, wraps its children in the provider, and each Tab/Panel calls useTabs() to get the current value — regardless of how deep it is in the consumer’s markup.

export function Tabs({ children, defaultId }: { children: React.ReactNode; defaultId: string }) {
  const [activeId, setActiveId] = useState(defaultId);
  const value = useMemo(() => ({ activeId, setActiveId }), [activeId]);
  return <TabsContext.Provider value={value}>{children}</TabsContext.Provider>;
}

export function Tab({ id, children }: { id: string; children: React.ReactNode }) {
  const { activeId, setActiveId } = useTabs();
  return (
    <button role="tab" aria-selected={activeId === id} onClick={() => setActiveId(id)}>
      {children}
    </button>
  );
}

export function Panel({ id, children }: { id: string; children: React.ReactNode }) {
  const { activeId } = useTabs();
  return activeId === id ? <div role="tabpanel">{children}</div> : null;
}

No activeId prop appears in the consumer’s JSX. The state flows through the context, so the markup stays flat and the children stay relocatable.

Failure mode one: leaking the context app-wide. Failure mode two: an unstable value that re-renders every consumer on each change. These are the two ways this pattern degrades, and both are about what the context is, not what it does.

Leaking: if you export TabsContext and provide it from a top-level app provider so “anything can read the active tab”, you’ve turned a component-scoped detail into global state. Now two Tabs on one page share one active id, unrelated code couples to your internals, and the encapsulation that made the pattern ergonomic is gone.

Identity: context consumers re-render whenever the provider’s value is a new reference — not when the data inside changes. A fresh object literal each render is always a new reference.

// BUG: new object every render → every Tab and Panel re-renders on ANY parent render,
// even renders that didn't change activeId
return <TabsContext.Provider value={{ activeId, setActiveId }}>{children}</TabsContext.Provider>;

// FIX: memoize so the reference is stable until activeId actually changes
const value = useMemo(() => ({ activeId, setActiveId }), [activeId]);

setActiveId from useState is already stable, so the only real dependency is activeId. With the useMemo, switching tabs re-renders only what depends on the change, not the whole subtree on every unrelated render.