Migrating behind a facade: same components, new tool
Badge and AddButton are written once and work with both implementations, so the switch touched only the cart module. The new version is also cheaper: AddButton no longer re-renders when the cart changes, because it selects a stable action instead of reading the whole context.
Choose by the kind of state, not by fashion: local state and the URL first, a query cache for server data, context for rare global values, and a small store (Zustand, Redux Toolkit, Jotai) only for busy global client state, introduced and migrated one feature at a time.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
For a chat app, choose a home for: the list of conversations, the open conversation id, the message being typed, the online status of friends (pushed over a WebSocket), and the notification sound setting. Justify each.
Write facade hooks useTheme() and useSetTheme() for a theme that currently lives in context, so you could later move it to Zustand without touching components.
Explain it without notes
How do you decide which state management tool to use in a new React app?
Why is "TanStack Query + a small client store" such a common combination, and how do the two interact?
How would you migrate a large app from one state library to another?
What signs tell you an app's state design needs work?
Preview
Console
Nothing logged yet.Expected console output
old render Badge
old render AddButton
new render Badge
new render AddButton
click old
old render Badge
old render AddButton
click new
new render Badge