Reducers

Reducers handle the logic of updating the application’s state. They are activated using ACTIONS and return an updated copy of the state. ACTIONS contain the information which enables reducers to perform their job.

The business-logic-related ACTIONS in our simple application are task-oriented, so what do we need?

Load (or fetch)

Set all tasks

Update task

Remove task

So our actions file for tasks looks like this:

Each actions requires the type (which is a string) and the payload (which is an object). The meta is optional and can contain any information that may help you track or log the operations.

You’ll note that each task starts with the [Tasks] prefix so we could differentiate between similar tasks for different object types. These ACTIONS are now ready for use in a reducer. Currently we only need one reducer - tasksReducer:

This reducer receives the current state, manipulates it, and returns the updated version (line 14 in the store). The new state is then updated in the store (line 17 in the store). Now our immutable store can handle the changes, and keep everything that’s flux-related in check.

When we add new reducers, we need to be careful and keep in mind that the order in which reducers are introduced to the store is important, because each reducer will add after the first one, will get the updated state from its predecessor.