The Action dispatched by the action creator can be picked up by many reducers. There is a common misunderstanding that there should be a one-to-one mapping between Action creators and reducers. So how do we update the state on two places from one action creator? That means that it belongs to one action creator. It can be tempting to create two Action creators in this case because two state changes should happen.īut the user does one action: closes the modal. We need to do two state changes simultaneously. When the user clicks the save button two things should happen simultaneously: It should update the Redux state with the newly inputted data, and it should close the modal by changing the UI state. Let’s say you have a modal where you can edit the username in a text field. Use case: Multiple simultaneous state changes In our day to day programming sessions we can use a simple rule of thumb:Ī user action should be an Action creator. Redux includes a utility function called bindActionCreators for binding one or more. Use "delete-user" rather than breaking it up into "delete-user-id", "clear-user-data", "refresh-credentials" (or however the process works) An action creator is merely a function that returns an action object. They should not describe implementation details of that action. Actions should be semantic and descriptive of the action taking place. The Flux documentation has an interesting description of how Actions should be used. Component A user action is a Redux action This means it is possible to use it “wrongly”.Ĭonsider the following component calling action creators:Ĭlass UserForm extends React. There is no limitation on what you can name it or what it should do. It means that you as a developer can use it any way you want. You have a separate test for state changing logic and the logic that happens before a state change.Īn Action creator is just a regular JavaScript function. Decoupling is a good practice for clean code. The “what happened” and “how to change the state” are decoupled. Or that Redux is being used to change the state.Įasy to reuse components in other contexts where state changes should be handled in another way. It doesn’t even need to know that the state is changed at all. The calling component doesn’t need to know how to change the state. The Actions handles “what happened” and the Reducers handles “how to change the state”.īecause of this design decision, the components calling Actions only needs to know one thing: “what happened”. The original author Dan Abramov recently had an interesting Twitter thread where gives the answer. Redux Actions and Reducers are not separated by coincidence. Have you ever thought about why Redux uses Actions and Reducers for state changes? Why are they separated? There are some best practices created from experience by the community and the Redux/Flux authors that you can use as tools when you get stuck. That makes it difficult to pick the best one. But you don’t yet have the experience to know what are the pros/cons to each solution. When coding complex Redux applications, you can come to a situation where you have more than one potential solution to a given problem.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |