Do we need to provide state and dispatch in separate providers or can we export them from the same provider??

it makes a lot of sense to keep dispatch and state in separate contexts if there are quite a lot of components in your app that largely only use dispatch and hence they will not re-render if the state changes. Even if we memorize contextValue with the useMemo hook, contextValue will still be re-evaluated every time we update the state's value, causing all components depending on the context to rerender, even some of them only depend on dispatch only.

Advanteges of this aproach:

1
Components consuming only won't re-render when the state changes, thus optimizing performance.
2
StateContext provides the state to components that need it.
3
DispatchContext provides the dispatch function to components that need to trigger actions.

javascript

Difficulty: 5/10

Topics: React Context, useReducer, Provider pattern

Scenario Questions

0-2 years experience

1
You have a tiny counter component that uses useReducer. How would you make the count and the dispatch function available to its child components – in one context or two, and why?
2
If you accidentally create two separate providers, one for state and one for dispatch, and a child only consumes the state context, what will happen when it tries to call dispatch?

2-5 years experience

1
While adding a new feature, you need many unrelated components to read global state and trigger actions. Walk me through how you’d structure the providers and the trade‑offs of a combined provider versus separate state and dispatch providers.
2
During a code review you notice a component importing only the state context but calling dispatch, causing a runtime error. How would you debug and resolve the issue?
3
You want to lazy‑load a part of the app and avoid recreating the reducer on each render. Does using a single provider versus separate ones affect this, and how?

5-8 years experience

1
In a large app with dozens of reducers, you consider giving each reducer its own state and dispatch contexts. Discuss the performance implications and how you’d prevent unnecessary re‑renders. Would a single combined provider be preferable?
2
Design a reusable ContextProvider component that can optionally expose state, dispatch, or both. Explain how you’d keep type safety and avoid prop drilling.
3
Your app is leaking memory because a provider is recreated on every route change. How could consolidating state and dispatch into one provider help, and what pitfalls must you watch for?

8+ years experience

1
Your team is migrating a monolith to a micro‑frontend architecture. How would you decide whether to keep a single global context that exports both state and dispatch, or to split them into separate providers per domain, considering versioning, team ownership, and bundle size?
2
You need to support multiple versions of a shared UI library that each expects a different shape of the context value. How would you design the provider/export strategy so legacy and new code can coexist without breaking?

Follow-up Questions

❓What impact does this choice have on component re‑render frequency?
❓How would you type the context values in TypeScript?
❓Can you think of a scenario where splitting them would cause bugs?