You own a shared React module that other teams consume — say a <FeatureFlagProvider> plus hooks. What do you decide about its public surface: what to export, whether the Provider owns its own state, and whether two instances may coexist?

## Why this is a design problem, not a coding one Once other teams depend on your module, everything you export is a contract you have to keep. Context modules are especially easy to over-expose because the pieces feel innocuous — a context object, a value type, a helper — and each one silently licenses a usage you will later want to forbid. ## Decision 1 — the export surface The defensible default is narrow: the Provider component, one or two hooks, and the types the hooks return. The context object stays private. Exporting the context object licenses two things you probably do not want. Consumers can mount their own Provider with a hand-made value, so your invariants (this value is always fully loaded, these fields are always consistent) stop holding anywhere in the app. And consumers can read it directly, which freezes the internal value shape: split one context into two later and you break them. But refusing to export it creates a real gap — tests, Storybook, and embedded previews genuinely need to inject values. Fill that gap on purpose rather than by leaking the context: ```jsx // Purpose-built, documented, and narrower than exposing the context export function FeatureFlagTestProvider({ flags, children }) { /* … */ } ``` A named test surface is better than an exported context, because you control its shape and can keep it honest as the internals move. ## Decision 2 — who owns the state There are three shapes, and the choice is a genuine tradeoff. **Provider owns everything.** It fetches or computes internally and exposes the result. Adoption is one line; nobody can get the wiring wrong. The costs are real, though: the consumer cannot seed it for tests or server-rendered data, cannot decide when the work happens, and cannot share the same data with non-React code. **Provider is a pure carrier.** It takes `value` as a prop and the app owns the state. Maximally flexible, trivially testable — and it pushes all the wiring, and every chance to get it wrong, onto every consuming team. **Uncontrolled with an escape hatch.** Owns state by default, but accepts an optional initial value, or a fully controlled `value` prop that takes over when supplied. This is the pattern most component libraries land on, and it is usually the right answer here too: easy adoption for the common case, a documented door for the hard case. Be explicit in the docs and the types about which mode is active, because a prop that is sometimes-controlled and sometimes-not is exactly the ambiguity that produces bug reports. Whichever you pick, expose behaviour rather than raw internals. Returning `{ isEnabled(name) }` lets you change the storage completely; returning the raw flags object means every consumer's code depends on that object's shape forever. ## Decision 3 — may two instances coexist? Because a consumer reads the *nearest* Provider, a second mount deeper in the tree creates an independent scope. You must decide what that means for your module and make the decision visible: - **Per-instance is the point.** Correct for anything inherently scoped — a form, a wizard, a widget instance. Document it and name the Provider so it reads as scoped. - **Exactly one is intended.** Then a nested second instance is a misconfiguration, and it will present as "my flag update didn't take effect over here" — an expensive bug to chase. Detect it: have the Provider read the context itself and warn during development when it finds an existing one. ```jsx function FeatureFlagProvider({ children }) { const existing = useContext(FlagContext); // private context if (process.env.NODE_ENV !== 'production' && existing) { console.warn('Nested <FeatureFlagProvider> detected; the inner one shadows the outer.'); } // … } ``` A related failure is worth pre-empting in the docs: if two copies of your package end up in the consumer's dependency tree, the Provider and the hook resolve *different* context objects and the hook reports a missing Provider even though one is mounted. Say so, and name the fix. ## The rest of the contract - **Failure mode.** Throw from the hook when no Provider is found, with a message naming the Provider. Silent nulls in a shared module become someone else's afternoon. - **Types.** Narrow inside the hook so consumers get a non-nullable type. A nullable type exported to twenty teams generates twenty redundant checks. - **Versioning.** Every exported name is a semver commitment. Fewer exports means more freedom to change internals — which is the whole point of keeping the context private. - **Environment constraints.** Be explicit about where the Provider may be mounted in the consumer's app, since a Provider carrying state and callbacks is inherently a client-side component. ## What interviewers listen for They want you to treat the module as an API with a blast radius: to say what you are deliberately *not* exporting and why, to pick a state-ownership model with its cost stated out loud, and to have an answer for two-instances and for duplicate copies of the package. "Export the context so people can do what they need" is the answer that fails this question.