Redux: Describing State Changes with Actions
You will learn how Redux asks you to describe every change in the application state as a plain JavaScript object called “action”.
We are presenting a “complete” example in the code window below. Feel free to click around and explore! We will be explaining what everything does during this course.
[00:00] The second principle of Redux is that the state tree is read only. You cannot modify or write to it. Instead, anytime you want to change the state, you need to dispatch an action.
[00:13] An action is a plain JavaScript object describing the change. Just like the state is the minimal representation of the data in your app, the action is the minimal representation of the change to that data.
[00:29] The structure of the action object is up to you. The only requirement is that it has a tie property, which is not undefined. We suggest using strings, because they are serializable.
[00:41] In different apps, you're going to have different types of actions. For example, in a counter app we only have increment and decrement actions. We don't pass any additional information, because this is all that is needed to describe these changes.
[00:57] But say, for a counter release example, we have more actions. We have add counter action, we have a remove counter action, and anytime I change the individual counter, you can see that the increment and the decrement actions now have index. Because we need to describe which particular counter was changed.
[01:24] This approach scales well to medium and complex applications. Anytime I add a todo, the components don't really know how exactly it's been added. All they know is that they need to dispatch an action with a type, add todo, and the text of the todo and a sequential ID.
[01:45] If I toggle a todo, again, the components don't know how it happens. All they need to do is to dispatch an action with a type, toggle todo and pass in the ID of the todo I want to toggle.
[01:59] The same is true for the visibility filter. Anytime I click on this control to change the currently visible todos, what really happens is this component dispatches an action with a type, set visibility filter, and pass in the desired filter string, filter filled.
[02:19] But these are all plain objects, describing what happens in a wrap.
[02:26] Now you know the second principle of Redux -- the state is read only. The only way to change the state tree is by dispatching an action. An action is a plain JavaScript object, describing in the minimal way what changed in the application. Whether it is initiated by a network request or by user interaction, any data that gets into the Redux application gets there by actions.
Why is an id needed for action ADD_TODO? An action should be minimal? In my opinion, the new id should be generated by looking at current state, so in the reducer, not in the action.
Correct?
What are the benefits of dispatching actions to change the state? Why can you not modify or write to the state? Also, what are the benefits of having a serializable value in the type property of an action?
Nice question. Making actions the mode of interacting with the state makes development declarative. You don't have to explicitly say 'make an array, sort it, then do this' - you just say 'CREATE_ORDERS' or something intuitive like that. It makes the development process so much easier - future developers need not know how the state change is being implemented as long as the actions work. Plus, you minimize the chances of fucking up your state when you allow only reducers to manipulate it.
What are the benefits of dispatching actions to change the state? Why can you not modify or write to the state? Also, what are the benefits of having a serializable value in the type property of an action?