That means the component will re-render after every dispatched action, even if the input state.todos slice hasn't changed: This is especially common with array operations like map() and filter(), which return new array references.Īs an example, this component is written badly, because its useSelector call always returns a new array reference. If a selector always returns new references, it will force the component to re-render even if the derived data is effectively the same as last time. useSelector and mapState rely on = reference equality checks of the return values to determine if the component needs to re-render.Re-running expensive calculations when the input state sections didn't change is a waste of CPU time, and it's very likely that the inputs won't have changed most of the time anyway. Selectors used with useSelector or mapState will be re-run after every dispatched action, regardless of what section of the Redux root state was actually updated.
This can be a concern for application performance, for several reasons: Selector functions often need to perform relatively "expensive" calculations, or create derived values that are new object and array references. You don't care about exactly how the query came up with the data you needed, just that you asked for the data and got back a result. One common description of selectors is that they're like "queries into your state".
USESELECTOR REACT REDUX UPDATE
Ideally, only your reducer functions and selectors should know the exact state structure, so if you change where some state lives, you would only need to update those two pieces of logic.īecause of this, it's often a good idea to define reusable selectors directly inside slice files, rather than always defining them inside of a component. Then, you can use a given selector function many times in the codebase, anywhere that your app needs to retrieve that particular data. So, in the same way that we recommend using action creators to encapsulate details of creating actions, we recommend defining reusable selectors to encapsulate the knowledge of where a given piece of state lives. What happens if you need to make a change to where that piece of state lives? You would now have to go change every useSelector hook that references that value. Imagine that you've got several components that need to access that field. But, it might not be the best idea architecturally. The original state is still there as a reference and isn't being replaced.Less logic is needed to calculate those additional values and keep them in sync with the rest of the data.Similarly, a check for whether all todos have been completed, or number of todos remaining, can be calculated outside the store as well. As an example, a todo app would keep an original list of todo objects in state, but derive a filtered list of todos outside the state whenever the state is updated. This includes things like calculating filtered lists or summing up values. We specifically recommend that Redux apps should keep the Redux state minimal, and derive additional values from that state whenever possible. Additional tools and libraries for creating selectors.
USESELECTOR REACT REDUX HOW TO
0 kommentar(er)
