As applications grow so does complexity and the handling of state. Redux is a state container (a client-side database) that solves this problem. In a series of three we will look into Redux and take a peek at the fundamentals.
This blog post is suitable for intermediate front end developers who are starting out with Redux.
A common pain point when building large-scale applications is the tight coupling between user interactions and state changes.
For example, consider an app for managing email. Clicking an email must:
- Replace the “inbox view” (the list of emails) with the “email view” (the email the user clicked)
- Mark the email as read locally
- Reduce the total unread counter locally
- Change the URL of the browser
- Send a web request to mark the email as read on the server
There is a lot of state handling going on here. The function in the top-level component that handles a user clicking on an email must describe all the state changes that occur.
If you are new to the concept of state I suggest you check out my article Top 5 best practices when getting started with React for an explanation on the subject.
Facebook was running into this problem with state so they invented Flux.
From Flux to Redux
As Facebook open-sourced the Flux design pattern, the community responded by writing tons of different Flux implementations.
Redux by Dan Abramov is one of the most popular implementations due to its simplicity and awesome developer experience (live code editing combined with a time traveling debugger).
Redux has only about 100 lines of code (stripped and minified), so it is actually possible to look into the code itself and understand it without too much of an effort.
3 core principles of Redux
Redux has three core principles that you need to understand:
- One Immutable store
- Actions trigger changes
- Reducers update state
The first principle is that all application state is kept in one immutable store. Having one immutable store makes debugging and testing easier, allows server rendering and actions like redo / undo possible.
The second principle is that when a user performs an action i.e. clicks on a submit button in a form (a user intent). It triggers a change and passed on to the store.
This example is taken from the course on Redux by Cory House at Pluralsight. All cred goes to him.
A chat with Redux
Action – Thanks React! I will dispatch an action so reducers that care can update state.
Store – Thanks for updating the state reducer. I’ll make sure that all connected components are aware.
React-Redux – Woah, thanks for the new data Mr. Store. I’ll now intelligently determine if I should tell React about this change so that it only has to bother with updating the UI when necessary.
When to use Redux?
So when to use React only and when to add Redux on top of that? The answer to when you should add in Redux is a matter of preference. Pete Hunt described it like this:
If you aren’t sure if you need it, you don’t need it – Pete Hunt on Flux and Redux
In this episode of “An introduction to Redux for beginners” we have looked at the fundamentals of Redux and when and why it can be used. In the next episode, we will look at some hands-on code examples and how to structure Redux on a fundamental level.
If you can’t wait until then I suggest you check out this great podcast featuring the creator of Redux – Dan Abramov. Perhaps its time for a break. Put on your running shoes and rest your eyes for a while!