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.
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.
The structure of the action object is up to you. The only requirement is that it has a
type property, which is not
undefined. We suggest using strings, because they are serializable.
In different apps, you're going to have different types of actions. For example, in a
counter app we only have
DECREMENT actions. We don't pass any additional information, because this is all that is needed to describe these changes.
But say, for a counter list 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.
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_COUNTER, and the
text of the todo and a sequential
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.
The same is true for the
visibilityFilter. 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,
But these are all plain objects, describing what happens in a app.