Split your Redux Store into Multiple Reducers

Jamund Ferguson
InstructorJamund Ferguson
Share this video with your friends

Social Share Links

Send Tweet
Published 3 years ago
Updated 3 years ago

As we start to put more data and logic into redux.

One of the first thing that happens is that we break out our root reducer into multiple reducers, sometimes called slices, which are meant to represent “slices” of data in your application.

To achieve this we rely on the combineReducers method from redux.

Once we split up out reducers, I then show how to access the state using the namespaces we just created and share some best practices for naming actions.

Note

The redux style guide suggests modeling actions as events and not setters. For example rates/ratesReceived instead of rates/setRates. This encourages the pattern of listening for actions across multiple reducers.

Instructor: [0:00] Let's start off by creating a folder called store within our source directory and putting two new files into it, one called user.js and another called rates.js. We'll also move our existing store file into the store folder. Make sure our other files are aware of the change.

[0:17] Go back into store.js, and basically copy the whole reducer into rates.js. We'll rename it into rateReducer, and we'll export it as a function with that name. Also, need to copy over the initial state.

[0:32] In user.js, we're going to create a user reducer. Type "export function userReducer." That's also going to take state in an action, but for now it's just going to return the state. We also need to provide it with an initial state. Initial state = object. We'll have a name value, for which put in your own name. I'll put in mine and something like logged in, which we can say is false.

[0:54] We'll make sure to put initial state as the fallback if no state is provided. Now, we have a basic user reducer, and we have a rates reducer. We split up our Redux store into multiple slices. Now, let's join them back together.

[1:07] Go into store.js. With our import statement, we also need to import a new function called combineReducers. We can get rid of all the old reducer code. Let's also import userReducer from ./user and ratesReducer from ./rates.

[1:23] Then, inside of our createStore method, we will pass in combineReducers. That's going to take an object where we can add in our reducers with a key to namespace them. We'll have our user reducer with the user key and our rates reducer with the key of rates.

[1:38] One thing that may not be obvious here as we combine these reducers is that our data is now going to be stored in namespaces, the user data under user, and rates under rates. Any time we are accessing something like state.amount, it's now going to be accessed at state.rates.amount. Similarly, state.name is going to be accessed with state.user.name.

[2:02] We need to go through the application now and update all the places that were directly relying on calling state.amount or state.currencyCode. For us, there are just two instances of that. Both of those are inside our exchange rate file. We can update that to state.rates.amount and state.rates.currencyCode.

[2:19] You should see the application now works. It's also a common practice when you split up a reducer to standardize the naming convention of your actions. For that, if you go back into the rates store, let's change these to rates/amountChanged and rates/currencyCodeChanged.

[2:35] Let's look for any usages of those and update them to the new name. Currency code picker, it'll now be rates/currencyCodeChanged and in amount field, rates/. All that in place, we now have a multi-reducer application with our store split up into slices of users and rates. You can see the application is still working as expected.

egghead
egghead
~ 10 minutes ago

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today