The Redux Flow Simplified
Redux is a one-way street; the flow of data is unidirectional and that’s one of the core advantages of implementing Redux. The flow of Redux can be broken into 3 chronological processes which we will now dissect below!
I designed the diagram above to be as simple and comprehensive as possible. When diving into Redux, the flow of data can easily confuse novice programmers (myself included!) which is why I tried to break it down into a 3-part system. Now that you’ve gotten a visual representation of how data flows in Redux, let’s dive into each piece individually in order to truly understand how our data travels.
1 — ACTIONS
The Redux flow ultimately starts with an ACTION. A dispatch is first sent from the UI following a change made on the frontend (i.e. A user clicks a like button on a friend’s photo). This dispatch contains a payload which will carry data about our particular action and how it will modify our state to the second part of the Redux flow…
2 — REDUCER
Our REDUCER acts as the main hub where all of our actions are dispatched. The reducer takes in our initial state as well as the dispatched action and matches it to the corresponding reducer function. The purpose of this is to determine what modifications we would like to make to our state, and rather than directly altering the state, it makes a copy with the specified modifications. This updated version of our state will be held in something called a Redux Store…
3 — STORE
The Redux STORE is what holds all of the state for our entire application. The only way for you to alter its inner state is by dispatching an action to it (but not without hitting our reducer first). Because of Provider as well as Connect, our store becomes accessible to any connected component which is how it is able to update what is rendered by said components. The main takeaway should be that Store plays the role of storing our state as well as making changes to any corresponding components.
CONCLUSION
Just to recap, the Redux flow consists of 3 chronological steps in this order..
Action
— Tells us how we want to modify our state
— Dispatched to reducer from UI
Reducer
— Takes in action and initial state
— Matches action key with corresponding function to determine what changes to make to our initial state
— Updates the State of our store
Store
— Holds the state of our entire application
— Accessible to components through Connect()
— Changes in store (state) result in changes to the corresponding components
