Your team is starting a React Native sneaker store for users on low-end Android phones; how would you choose between Context, Redux Toolkit, Zustand and Jotai for client state?

## Step one: shrink the problem Most state in a sneaker store is **server state**: the catalogue, stock levels, prices, order history. That data is owned by the backend, goes stale, and needs caching, refetching and deduplication; a server-state cache does that better than any client store. Once it is removed, what remains is usually small: - the cart and its quantities; - filters and sort order that must survive navigation; - UI flags such as a dismissed promo sheet; - session information such as the signed-in user and theme. The library choice is about this remainder, and it is often smaller than the team expects. ## The criteria that differ on React Native | Criterion | Why it matters on a phone | What it favours | |---|---|---| | Change frequency times consumers | every re-render runs on the single JavaScript thread; low-end Android has the least headroom | selector-based stores for hot state | | Access outside the React tree | Headless JS tasks, notification handlers and API modules must read and write state | an importable store object | | Persistence and hydration | state is restored from on-device storage at every cold start | a library with a clean persist story for your storage | | Team size and turnover | many authors need one obvious pattern | enforced structure | | Debugging | you need to see what changed and why | action logs or devtools support | ## How the four options land **Context** is not a state manager; it is a way to pass a value down. It is excellent for values that change rarely and are read widely, such as theme, locale and the user. It is a poor home for the cart on a low-end device, because every consumer re-renders on every change and it cannot be read outside the tree. **Redux Toolkit** gives slices, action creators, middleware and a single store. Its strengths are **predictability and structure**: every change is an action, which helps debugging and code review in a large team, and the store is importable anywhere. The cost is ceremony that a small app may not need. **Zustand** gives a hook-based store with selectors and very little boilerplate, and its store is also importable outside React. Its weakness is the flip side: with no enforced structure, a large codebase can drift into many inconsistent stores unless the team sets conventions. **Jotai** models state as small atoms that components subscribe to individually, which suits many independent pieces, such as per-product UI state, and gives fine-grained re-renders by construction. It is less natural for one central entity like a cart with business rules, and out-of-tree code must use the same store object the `Provider` uses. ## A recommendation, and its conditions For a sneaker store built by a small team: 1. server data in a query cache; 2. the cart in **Zustand**, with narrow selectors and actions that outside code can call; 3. theme and user in **Context**. For a large team or one with Redux experience, **Redux Toolkit** for the cart instead, taking the ceremony in exchange for one pattern everyone follows. Either way, avoid mixing all four; each extra library is another mental model for every new hire. ## How to make the decision stick - Write it down with the criteria above and the device you are optimising for. - Prototype the hardest screen, usually the catalogue list with cart badges, and measure it on the slowest supported Android device in a release build. - Revisit when the client core grows, for instance when offline edits or complex multi-step flows arrive; a choice that fits a small core may not fit a large one. There is no single right answer. Interviewers are looking for the order of reasoning: subtract server state, measure the render cost on real devices, and match the library's structure to the team that will live with it.