Redux is a very simple tool that is very poorly explained. In this article, I will explain Redux in a single sentence that is sorely missing from the Redux documentation.
Redux is a pattern for modifying state using events.
That’s it. It’s a dedicated event bus for managing application state. Read on for a more detailed explanation, and for a specific explanation of the vocabulary used in Redux.
1. Redux is a design pattern.
The first thing you need to know is that Redux is not really software per se. True, you can download a Redux “library”, but this is just a library of convenience functions and definitions. You could implement a Redux architecture without using Redux software.
2. Redux is an extension of the Observer Pattern.
I think this is the only bullet point needed to explain Redux to experienced developers.
The observer pattern is the abstract definition of what programmers refer to as events and event listeners. The observer pattern defines a situation where one object is listening to events triggered by another object.
Redux is a dedicated event bus for managing internal application state using events.
So redux is a way of triggering pre-defined events to modify state in pre-determined ways. This allows us to ensure that state isn’t being modified in ad hoc ways and it allows us to examine the history of application state by looking at the sequence of events that led to that state.
3. Actions are event definitions. Reducers are state modifiers.
The new vocabulary used by Redux makes it seem like it’s something new, when it’s really just a slight twist on existing technology and patterns.
Action = Event definition. Like events in any language, events in Redux have a name and a payload. Events are not active like classes or methods. They are (usually) passive structures that can be contained or transmitted in json.
Reducer = Event listener. A reducer changes application state in response to an action. It’s called a Reducer because it literally works like something you would pass to the reduce function.
Dispatch = Trigger event. The dispatch method can be confusing at first, but it is just a way of triggering the event/action. You should think of it like the methods used to trigger exceptions in most languages. After all, exceptions are just another variation on the Observer pattern. So dispatch is like throw in Java or raise in Ruby.
4. Redux manages local state separately from the backend.
Redux is a pattern for managing only the internal state of the application. It does not dictate anything about how you talk to your API, nor does it dictate the way that your internal state should be connected to the backend state.
It’s a common mistake to put the backend code directly into the Redux action or reducer. Although this can seem sensible at times, tightly coupling the local application state with backend interactions is dangerous and often undesirable. For instance, a user may toggle a switch three or four times just to see what it does. Usually you want to update local state immediately when they hit the switch, but you only want to update the backend after they have stopped.
Redux is not complex. It is a dedicated event bus for managing local application state. Actions are events. Reducers modify state. That’s it. I hope that helps.
Here are a few other useful links: