@reduxjs/toolkit
Version:
The official, opinionated, batteries-included toolset for efficient Redux development
29 lines (20 loc) • 1.14 kB
Markdown
# State Ownership Heuristics
## Choose the owner, then the tool
| Kind of state | Default owner | Typical tool |
| --- | --- | --- |
| Editable form fields | Component | `useState` |
| Shared mutable app data | Redux | Slice state |
| Server cache | RTK Query | `createApi` |
| URL, pathname, search params | Router | Router APIs plus selector inputs |
| Browser-only authority like `localStorage` | External source | Read at boundaries, then dispatch events |
## Good reasons to move data into Redux
- Multiple distant parts of the UI need the same mutable data.
- You need time-travel debugging or a stable action history.
- The reducer should own transitions because they mix old store state with new inputs.
## Reasons to keep data out of Redux
- Another system already owns it, such as the router.
- It only matters during editing inside one component tree.
- It is server cache and RTK Query fits the use case better.
## Re-evaluate slice size
- If data is constantly stitched together outside reducers, it may belong closer together.
- If unrelated updates keep touching the same slice, split the slice by domain ownership.