Reputation: 46900
The NGRX official demo application keeps layout state in the store.
This Akita Article also keeps state like searchTerm
etc in the Akita EntityStore<Book>
.
Just curious whether there there are additional benefits to keeping user interface state in the store, instead of only in UI components?
Upvotes: 1
Views: 331
Reputation: 3156
One thing to consider is when you use component state and a component is unmounted and remounted again, it's state is generally lost. If the component stores all of it's state in redux, then it's state can be kept.
This is often a factor when I use react-router in conjunction with redux. Some pages I want to navigate away from and return to them in the same state.
Upvotes: 2
Reputation: 67459
Per the Redux FAQ entry on how to split state between the store and components:
There is no “right” answer for this. Some users prefer to keep every single piece of data in Redux, to maintain a fully serializable and controlled version of their application at all times. Others prefer to keep non-critical or UI state, such as “is this dropdown currently open”, inside a component's internal state.
Using local component state is fine. As a developer, it is your job to determine what kinds of state make up your application, and where each piece of state should live. Find a balance that works for you, and go with it.
Some common rules of thumb for determining what kind of data should be put into Redux:
- Do other parts of the application care about this data?
- Do you need to be able to create further derived data based on this original data?
- Is the same data being used to drive multiple components?
- Is there value to you in being able to restore this state to a given point in time (ie, time travel debugging)?
- Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)?
Upvotes: 3