# 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.