Redux

8.16.21

Redux seems to be slippery for a lot of newer developers to get a firm grasp on. At a quick glance some definitions and examples can seem both very vague and very complicated at the same time. Redux comes with an entire new vocabulary that can be a little intimidating as well – we’ve got a store, actions, dispatchers, reducers, thunks… all for managing application state. Even the term ‘state’ might be a little foreign to developers who primarily develop with backend technologies. Let’s simply break down some of these terms and lift the veil of obscurity on Redux.

Let’s clear up that state issue before anything else. I found an eloquent quote from Stack Overflow: “An application’s state is roughly the entire contents of its memory.” Application state is data that is stored in memory on the server or locally. Using application state is useful because it is faster than storing and retrieving information from a database.

Ok now that everybody is clear on what state is – Redux is an open-source JavaScript library for managing and updating application state. Redux is not a React specific library but I will be talking about it in the context of React. Redux is not really for state between components but for global or app wide state and works best with applications that have a large amount of global state that is accessed by many of the application’s components. A main goal of using Redux is scalability for managing these large amount of global state.

The store – the heart of Redux is the store. The store (there should be only one per Redux application) is an object that holds the application’s state tree. The store holds the state. The reason that is important is because the store has the ability to update the global state of an application which would affect elements of the application’s UI. The global state in the store should never be accessed directly, that is done through functions provided by the store. While researching this I came across an analogy that I will paraphrase. The store can be thought of like the vault in a brick and mortar bank. In order to access contents of the vault, you must fill out a withdrawal form and speak to a teller, maybe a manager if you want large amounts of content. The point being, you can’t just walk right up to the vault. Before we get into those functions to access the vault, now would probably be a good time to mention the one way data flow of Redux.




Straight from the official Redux docs. It’s not stealing if my CodeCademy Pro 10 hour Redux certification course can use the identical gif (very humble flex). So the data flows from state to view to action back to state and so on.

Actions – the only way to get data into the store. An action is just a JavaScript object that represents an intention to change the store’s state. It is an event that describes something that happened in the application. An action has only one required field (even though it can have many more and the structure is customizable) and that is type. The type field should be a string that gives the action a descriptive name. The standard naming convention is “domain/eventName”, where the first part is the feature or category that this action belongs to, and the second part is the specific thing that happened. An action object can have other fields with additional information about what happened. By convention, we put that information in a field called payload.

The way state gets changed is through Reducer functions. Reducers are functions (that accept actions) that are responsible for passing state to components. You can think of a reducer as an event listener which handles events based on the received action ( or event) type. So, a reducer takes in current state and an action and returns the new state based on the action it receives.

Dispatchers are Redux store functions that trigger events in an application. They let the store know about something that happened.

Finally we have the weirdest Redux vocabulary word – Thunk. As in the past tense for think, something like “I already thunk about it”. A thunk (not exclusive to Redux btw) is a subroutine used to inject a calculation into another subroutine. Or a function that is used to delay a computation until it is needed by the application. By default, JavaScript functions are thunks since they hold information and can be executed any time or passed to another function (to also be executed at any time). So, in Redux thunks can be used to hold asynchronous logic that interacts with the Redux store.

Without going too deep into the rabbit hole, that is essentially Redux at its core. Developing with Redux gives you access to some cool dev tools for monitoring, debugging and testing application state changes.

I have been working on an e-commerce site. For this project I am using Redux to manage the global state of users data, products, orders and as shown above, shopping cart items. In this case I am utilizing the local storage for the state.

Without getting into specific code, I think that is a pretty comprehensive conceptual introduction to Redux. We'll get into the code in another post.