Redux Revisited
What even is the store?
Let’s meditate on this code sample.
Some bad things we did (Or, a bit on container versus presentational components)
By “we,” I really mean “I”—which because you all just steal my code: “we.” Let’s look at some of our past mistakes and see how breaking stuff out into containers and presentational components might have been a better choice.
- That time I decided to handle both rendering and managing state in the Application component in Taskblaster.
- That time I took an otherwise reusable list component and messed it up with too much knowledge about Firebase.
We can do better, right?
What if we separated the concerns of figuring out how to get and update state from how we go about displaying our user interface.
Stop! Let’s spend 10 minutes and read this article and also this one too.
Together, we’ll look at this table.
Some thoughts:
- Maybe it’s not wrong to think of containers a bit more like controllers.
- This isn’t the right approach all of the time. Recall “You might not need Redux”. It’s all about figuring out where you want to make your trade offs.
The interplay between React and Redux
React and Redux are maintained by some of the same people. The repository for Redux is definitely under the the React organization on Github. But, beyond they’re not related. You can definitely use React without Redux and you can also use Redux without React.
We also have a library called React Redux. I’ll let you take a lucky guess as to what it does.
React Redux really only gives us two things:
The first is necessary to make the former work. connect takes care of wiring up a container to the Redux store and subscribe to updates. It effectively is the glue between Redux and React.
Let’s look at this section of a really great article on React and Redux to get a better sense of what’s going on.
