Transcript from the "Redux Overview" Lesson
>> Brian: So we're finally on Redux. [LAUGH] It took us awhile, but there's actually a reason why I structured it this way. Redux is a pretty big sledgehammer. Like it's a really heavy library. And it's not in the sense of page weight, but it really is going to cause you to refactor your application a lot.
[00:00:20] And it's over [COUGH] excuse me, it's overkill for almost all apps or in other words, I don't use Redux that much personally because it's way too much. Usually Redux does everything sufficiently. Like everything I just showed you, that's how I usually build apps. Until I get to a certain point where I just can't manage all of my state that way, and then I bring in Redux.
[00:00:46] Redux is a phenomenal library, but even the creator, himself, Dan says, this is not for every app. In fact, this is not for most apps. So my suggestion to you, if you're starting out building a new application, just start with React, Set State and Props is usually enough for just about everything.
[00:01:04] It's a really predictable, explicit way of managing your state, and React is really good at it. So that's my suggestion to all of you, is start with React until you hit the point where you say, I can't do this anymore, and then, we factor in to include Redux.
[00:01:21] And refactoring to include Redux is not super difficult. And to prove that to you, we're gonna refactor just a tiny bit of our app to use Redux instead of using reacts and set state, and stuff like that. So let's talk about what Redux actually is. Redux, itself, I like to say that Redux is a simple but hard library.
[00:01:44] Simple in the sense that there's not a lot to Redux. It's not a very big library, but actually it's pretty difficult to get your mind fully around everything that's going on. There's a gist out there somewhere that you can implement Redux in like 80 lines of code. The entire library in 80 lines of code.
[00:02:02] Now, the library itself, what's on GitHub, is much bigger than that but they include a bunch of convenience methods. But the core part of Redux is, there's not much to it. So it's a central repository of all of your state. So instead of keeping your data in like in each individual component, we just take all of that out and we put it into one giant central store.
[00:02:26] Now, why would we do that? That seems to kinda go against everything that I have just been telling you about. Well, sometimes having components splits a cost, multiple components becomes almost impossible to manage. Imagine that if you have to start animating components across the page and they have to have multiple transition that include multiple components all at once, it's really tough to orchestrate that across components to the point that it's almost impossible.
[00:02:52] It's really hard for for components to talk to each other and at by design. So instead of trying to make this crazy pub-sub system or something crazy like that to do it, what you do is you just externalize that all into Redux.
>> Speaker 2: Francois was asking, we hear about flux and redux.
[00:03:10] Can you talk about the differences between the two?
>> Brian: Yeah, I'm getting there. That's a good question.
>> Speaker 2: I'm just gonna hotkey that.
>> Brian: I'm getting there. [LAUGH] Yeah, I say that a lot, definitely true. Back to Redux. So you externalize all of your state into Redux.
[00:03:31] And I'm saying Redux right now but you can substitute Redux, flux, mobix into all these places that I have currently set Redux so far. Anyway, you externalize all of your state into Redux, and Redux is just like one central repository for all of your data. So now when you have to do multiple state changes across multiple components, because it all lives in one place, pretty easy to do.
[00:03:57] Cuz it's all available to you all the time. So that's kind of the value proposition about Redux. You bring all of your state into one place, and it's really easy to distribute that across your app. But your trade off there is you now have a hard dependency on Redux.
[00:04:17] And it's a lot less obvious to read your code. You're gonna come in there, you're gonna see this.props.something and you're not gonna know where necessarily it came from. It's gonna come from Redux so that'll become more concrete as we actually explore that.
[00:04:38] That's the best way to put it. It is not react specific. I think that's a pretty big key to note, as well. Redux works with angular, too. It works with all these other libraries. It just happened to be standardized with react first.
>> Brian: So where did Redux come from?
[00:04:57] I think that's kind of an interesting thing to note when you're talking about Redux. When Facebook launched React, they kinda ran into, especially with animations, animations are tough with React because of their kind of separate nature of all the different components. Especially when they're supposed to coordinate. There's a couple other reasons, as well.
[00:05:19] Like remember when we were doing shows and we had two different places that wanted to read from shows. So we had to push it up to a common ancestor. That happens a lot with Redux. It's a very common problem to have. And if you have to go through seven different layers it comes a pain in the ass.
[00:05:36] It ends up saying this process gets passed to this. You have to do several layers deep. It's called the data tunneling problem, and it's horrendous to deal with.
>> Speaker 2: Durante has a question. I think sort of back to just the previous topic. Isn't harder to understand where there's a bug since state isn't inside the component that you talked to that [CROSSTALK]
>> Brian: Yeah, absolutely, you lose that reliability for debugging, which is also a problem. Sort of, cuz you're centralizing your state in a different place. So if you have a state problem, you still know that you start with Redux. So it just means that there's a few extra steps.
[00:06:22] A few to quite a few extra steps debugging. It's still predictable. It's still a good way of doing code. Like, I'm not trying to rag on Redux at all. It's very good at what it does. But it just adds complexity to your system. And that's like been the theme of this entire workshop is like let's start with the simplest thing possible and let's do the simple thing until it gets hard.
[00:06:45] Then, let's add complexity to make it easier. That's kind of been then the factor, refactor of this entire workshop. This is a big step. All these previous steps I feel like are pretty no brainer, okay I understand why that's difficult, I understand why I have this tool, let's just do it.
[00:07:04] This is a big step and this is one you need to ask yourself a lot of questions before you take this step. It will become worth it if you have these problems that I'm talking about and it's not worth it. If you don't have these problems.
>> Brian: So going to back to redux and flux.
[00:07:24] Facebook came up with this idea of well, why can't we take this same idea with React and we have this one-way data flow. Cuz one-way data flow made interfaces really easy. Why don't we kind of apply that to statement management, as well?
>> Speaker 2: Question about does Netflix use Redux?
>> Brian: In some parts of the application. My team doesn't. That's because we built relatively small apps, and we have many small apps.
>> Speaker 2: Is it because you don't need a Redux type component?
>> Brian: Yeah, it just would be giant overkill for everything we do. So they introduced this idea Flux.
[00:07:59] This idea of one way data flow. And I'm not gonna get to much into it. You can go read the Flux ox. But it was a good idea it was just no quite all the way there. It wasn't full flushed out. Like they didn't release a library. They just kinda released this idea of the Flux idea.
[00:08:17] And then, a bunch of people did Fluxer, Flimix, Alt. There are all these different libraries that implement the flux pattern. Well, Dan Abramov, who's the guy that wrote half the shit that we're using today, he did hot module reload, he did redux, he did, and he now works at Facebook and does other things, as well.
[00:08:40] He works on reactive self. He was preparing a talk, I think it was for react Europe. And he wanted to just demonstrates some core concept about like hot module reload and some other things like that. So he came up with the hot reloadable Flux container and that kinda bore out Redux and that's actually what we're going to be using today, it's still pretty much the same premise.
[00:09:05] So that's kind of like Flux evolved into Redux. Redux is not Flux but everything, all those good ideas he just took the best parts of Flux and made Redux. If you do flux it you end up with a lot of complexity because with flux you have multiple stores and so trying to find your data across multiple stores ends up being really non intuitive.
[00:09:29] With redux everything just lives in one central repository. You have exactly one place to start which is always a good place to be with debugging. Let's go over what actually makes redux. Unless anyone has any questions before I start?
>> Brian: So again, I mentioned it I'm not gonna be talking about Mob X today.
[00:09:58] I'm not gonna be talking about any other kind of way of doing this Central State Repositories. You are welcome to check them out. They're all equally interesting. But Redux in my opinion is probably the best place to start. It's the simplest. Mob X is even more complicated. But does even cooler stuff.
[00:10:17] I don't say even cooler stuff, but it does really cool stuff.
>> Speaker 2: Question from Craig, clarify data tunneling is common in react or redux?
>> Brian: It's common in react and it's a problem that redux solves.
>> Brian: Just imagine if we had show cards and the show cards had a title component and the title component had, I don't know, something else inside of it.
[00:10:43] So we had to pass down title seven different layers, that's annoying because now you have a hard dependency in every one of those components of title. Each one has to receive title so it can pass it down. That's annoying, especially for a component that doesn't rely on being titled.
[00:10:58] It's just one of its children relies on it. It's an issue. And so, that's what Redux solves here. Is it takes that out and so it makes it just the component that needs it gets it. Any other ancestor components don't necessarily have to keep it.