Redux is a state Management Framework that is primarily used with React. There is an Angular port of it, ngrx. I wanted to learn a bit about Redux and write about it in the latest Bonus book for my Angular 6 series.
This is the first in a series of articles about Vanilla Redux. In this article we'll talk a bit about terminology used for Redux and how a Redux application should flow.
Understanding Redux Terminology
Many frameworks have their own terminology, so this section will explain some common terminology.
- Actions: Actions are a collection of data that you send to the Store. The object must have a type value to define the type of action. The action in Redux is similar to the EventEmitter you've probably used in your Angular applications, and are passed to the store using a dispatch() function.
- Action Creators: Action Creators are functions that return an action. Action Creators do not dispatch the action, only return it. It is a way to encapsulate your functionality for creating an action.
- Reducers: Reducers are a function that update the state of the application. It accepts the current state, and the action you are performing. Reducers should be pure functions, meaning they do not have any side-affects such as changing the arguments or calling non-pure functions. The reducer does not change the current state of the application because that would be a side effect. It only creates, and returns, a new state object.
- State: The state is an object that stores data for your application, such as items in a shopping cart, the user who logged in, or other information.
- Store: The store is a single object that holds all the application state. It can return the state using a getState() function. It registers or unregisters listeners using a subscribe() function. And it updates state via dispatch() function.
As we progress through this series, we'll cover each item in more detail.
Understanding Redux Flow
Redux has a unidirectional data flow. That means that data always flows in one direction throughout the app. I put together a diagram: Let's look at each box:
- Start in the top middle. You have a view which is waiting for action. This could be a user entering data or clicking a button. Technically this doesn't even have to be a view but could be any code in your app, such as the result handler of a remote service call.
- When an action occurs, the view will call the dispatch() method on the store and send in the action object.
- The store will, in turn, call the reducer() function. The current state and the new state are passed in as arguments. The reducer function will do some magic and return the app's new state.
- The store saves the new state.
- Then the store calls any listener functions. At some point your code must have called store.subscribe() so it could get notified when something changed.
- The listener functions run code and update the view. If they need access to the current state they can call the getState() method on the store.