Transcript from the "Introducing Redux" Lesson
>> Brian Holt: Hopefully, we had a good experience learning React. What we wrote was totally complete. I'm happy with that architecture, and I think you can scale that to, I personally scaled that architecture to large applications.
>> Brian Holt: Now we're going to introduce you to another concept, which is Redux, right?
[00:00:19] Redux is not married to React at all. They're two totally separate libraries. It was birthed for sure in the React community, hence, why it actually lives in the React JS repo. But it is totally acceptable to use Redux with Angular, with Ember, or by itself. Redux by itself Is not a particularly verbose framework for restoring data.
[00:00:46] There's actually a gist out there, that you can write Redux in 80 lines of code, bare minimum. And it's not like code golf or anything like that. It's actually just not, there's not a lot to Redux. That being said, it's hard, right? And I just wanna emphasize throughout this entire course, if any of this feels hard or unapproachable or anything like that, it's cuz it is hard, we're learning some hard stuff here.
[00:01:13] All of this stuff is hard. So I permit you to feel like this is hard, right? Sometimes it's good to have acknowledged that we're doing hard stuff together, right? That being said, we're about to do harder stuff together. Integrating Reacts and Redux is going to make our architecture more complicated.
[00:01:36] And you all see here, I want you to make your own judgement calls here. But it's going to make overly complicated to the point of what we're going to do was actually not worth it for this size of the application. But again that's my opinion and I want you to make your own decision.
[00:01:52] But I don't integrate Redux until further along in the project life cycle. I wait for Redux to become necessary before I integrate it. Which is what I'm gonna suggest to you as well.
>> Brian Holt: Redux was invented by Dan Abramov, really smart and nice guy. He based it on Facebook's Flex architecture and also a bit on Elm's architecture as well.
[00:02:21] So those kind of ideas combined in his mind, cuz he wanted to write a data store that was hot reloadable, what we were just looking that, and it came up with Redux. Redux is really similar to flux. A lot of you have probably heard of flux before, that came out at the same time as React from Facebook as well.
[00:02:43] And flux is a really interesting idea that you have data stores and you dispatch actions into the data stores which then modify themselves. And then update whatever view layer, in this case, React is subscribed to it. The difference between Flex and Redux is with Flex you have many stores, right?
[00:03:05] They're kind of like single concern stores. So for example, you'd have maybe a user store, and then you'd have a messages store, and then you'd have all these different kind of stores that worry about one particular thing. [COUGH] I attended a talk from a Facebook that told me on their ads product, at its height, it had over 100 stores on the page.
[00:03:31] Now, as you may imagine, that's a nightmare, right? Trying to figure out what data goes into what store is, at least at that scale, unscalable. It became more complicated than it was worth. And particularly, let's say we had an animation that we were animating a component across an entire page, right?
[00:03:55] That was almost impossible to do with Flux because you would have all these different stores that were asynchronously dispatching actions to each other and trying to coordinate that change across multiple stores. It's pretty much impossible. So Dan came up with this idea. We have this one application in React, right.
[00:04:16] And this React application is a tree of things. Well why can't we have our data mimic the way the reviews are stored, right? So why don't we have one tree of data? And that's how Redux was born, instead of having one, or instead of having many tiny stores, let's have one big store, but the big store is just a tree.
[00:04:36] And then each part of our application can just subscribe to one part of the tree, right? That's the basic gist. So yeah, you're gonna have one Redux store on a page. The top level function in a store in Redux is called a reducer, or root reducer. You're gonna hear the term reducer over, and over, and over again.
>> Brian Holt: And reducer is just a function that takes and state in an action and gives you back a new state, right. So given this store, in this particular state that it's in right now, and this action, this is the state that you get back out. This is really awesome, because that means everything is reproducible, right?
[00:05:20] Given this state and this action, you get this new state, right? So it makes everything extremely testable at every single level. And we're actually gonna do quite a bit of testing with Redux. One of the big strengths of Redux is it makes your state management very testable.
>> Brian Holt: So, and the way it addresses those kind of large changes, where it changes multiple things like that animation example that I previously gave is you have access to all of the state all at once, right?
[00:05:52] You can modify multiple things at once. So if you have those massive changes that you need to make, go right ahead, you're welcome to do so. So, this is kinda high level what Redux is gonna do for you.
>> Brian Holt: State management, right, it's a state management framework. So we're gonna be taking things out of React, right?
[00:06:13] Right now, React is managing all the state via its state, like this.state.whatever, and this.setState. We're going to take that data out of React, and we're going to stick it into Redux, right? So, we're kind of divorcing our data from React. Now I'm gonna assert to you, I think react does a really good job of managing state.
[00:06:35] However, you might get to a point at some point we have tons of components, all worried about the same state. And that's the point where we say, maybe I should use Redux now, right? Cuz imagine for a moment, let's say we had ten different routes, right? Each of those routes was very complicated, had lots of components, and they were all interested about the shows that we were requesting from the API, right?
[00:06:58] Our two options here is that we can either put all that data up into app.jsx and pass that down into every route. That's very burdensome, right? Or we can have some sort of centralized state container like Redux that will take care of all that for us. Does it make sense?
>> Speaker 2: When you say burdensome, you just mean from a development perspective, not from performance or-
>> Brian Holt: Yeah, development. From a maintainability and things like that, right? Cuz what you're gonna have is you're gonna have these shows at the top level and you're gonna have to pass shows in every single component.
[00:07:33] So now every single component inside of your application cares about these shows, right? This becomes a real problem if I have top level app and bottom level component down here. And there's ten components here in the middle, there's gonna have to be a bunch of components passing state from parent to child, parent to child, parent to child so it eventually lands at the bottom, right?
[00:07:53] Otherwise, I wouldn't have to have cared about that shelves component, right? But it's just kind of tying your data into your application structure. We call this a data tunneling, right? This alleviates the data tunneling problem. So with React we had a very tight loop, right? This outsets date, well, let's say, I typed into the input that kicks off an event that goes into our vent handler that they call set-state.
[00:08:19] The setState updates the state and it kicks off a re-render, right? Pretty tight circle. What we're gonna do with Redux is we're going to make that circle a little less tight, right? We're gonna expand that circle. So what's gonna happen is we're going to kick off an event.
[00:08:35] The event is gonna call the handler. The handler's going to dispatch an action to a Redux via an action creator, which is then going to get called into the reducer, the reducer is then going to modify its state. Once the state's been modified, it's going to notify React, which is a subscriber, which is then going to kick off a re-render, and then you have updated the state at that point.
[00:08:57] So we've added three or four more steps in there. So if that sounds more complicated, it is. So, tough I guess. So let´s go ahead and get started with that then. First thing I want you to do is create a new file called reducers.JS lower case r and not JSX, just JS.
[00:09:26] We're not going to have any React living in here, so that's why we're not gonna have any, there's no X on the end, and it's not a component so it's not a capital r. That's what those conventions mean.