This course has been updated! We now recommend you take the State Management with Redux & MobX course.
Transcript from the "Flux Introduction and Code Demo" Lesson
>> Steve Kinney: So, we explored a number of patterns for separating state from presentation. There's nothing about flux or redux or monax are unique to this. We could do this with regular react components as we just did. Right? Those [INAUDIBLE] components could fetch stuff from the network. They could fetch stuff from the local storage.
[00:00:27] Right? But there are some additional ways of thinking about state outside of just using set state as we've been using it so far this workshop. And so we're gonna talk a little bit about the flux pattern, and I just wanna, and I think it's sometimes interesting to think about the fact that for a lot of these patterns, the entire community's not in universal agreement that you need to use all of these all of the time.
[00:00:53] My job is to show them to you, to explain them to you, to kind of talk about some of the benefits and some of the trade offs, but not to sell you on that you have to use this one or that one or the other one. Right? And that is even in this case, and we'll see some work codes around this where it's the end in the conclusion.
[00:01:10] Right in form of secretive react radar, agrees that flux and redux are great ways to build an app, but wonder that if going whole hog into them and not considering these tradeoffs; not considering the different approaches that we can take and spending the time to figure out exactly what's right might be beneficial for us to do very cool.
[00:01:34] So, I'm gonna explain Flux but I'm gonna do it a little differently than what's normally done. Normally, when someone wants to explain Flux they show this crazy diagram, right, that overwhelms you and you get a little freaked out and then they start like pulling back the pieces. We're gonna do this in three steps.
[00:01:56] I'm just gonna start implementing Flux In the pizza calculator, and then we'll go and put together all the pieces so we would have seen it actually implemented and you don't have to stress out. We're going to do it twice because there a lot of moving parts and a lot of new terms and it can be a little crazy all at once.
[00:02:19] I think showing the chart, and then trying to get your way through it has not been particularly effective for me learning any of these patterns. And my suspicion is that it'll be easier if we see it in practice, pull apart the pieces, and then see it in practice again.
[00:02:35] Cool In the chat I did drop kind of the notes I'm going to use so if you want to like follow along, they're very bare bones because I need to get the general gist. They're not like a long form essay on that stuff, but you can also see that as we go along as well.
[00:02:53] Okay, so real quick, I also am back on the master branch, before we did all of our crazy patterns. In this case, I do wanna keep it kind of like, clean, and we don't have to mix in a bunch of like, container patterns and render pros patterns as well.
[00:03:08] Don't worry, we'll get there, but let's start with a clean slate. So what I am gonna do real quick, is I'm just gonna check out a new branch
>> Steve Kinney: We'll call it live coding flux, that way it doesn't have merge conflicts with the other live coding branch. So we'll call this one live coding flux and somebody has to remind me to commit and push up when we're done, very cool.
[00:03:36] Okay so, there are, the ideas to pull as much of like state just out of components as a whole, right? The idea is like if we do stuff in react one way or another we're going to have to life pass stuff down, right? Versus we take the state management out of react right, we have a lot more flexibility on how we pass it in.
[00:04:00] Reacts claims just to be a view layer, we've been handling a lot of, like, working with our data in our view layer, but it's not necessarily meant to do that, at a certain growth and complexity of your application, it makes sense to think about pulling this stuff out.
[00:04:16] Two things that I will say is when should you pull it out, I would say generally speaking unless you know this is gonna be the big app that you got in the next two years in your iphone it makes more sense to start in that state and wait till it hurts.
[00:04:30] The cool thing about the container pattern is if you start with the container pattern, you've already separated out the idea of managing state from your UI right. And so should you decide no arts It's not hard for you to refracture the entire app. If you go with, before where you explored all those patterns, and you just start jamming all of your state management and your presentation together than it's going to be painful to move to flux, or redux, or mobx.
[00:04:56] Right? I think the best programming decisions are the decisions that you can change your mind on later. So if you structure things to delay until the last responsible moment and give yourself enough wiggle room to change your usually better off than if you try to make the right choice at the very beginning of your project because you don't necessarily know how the project is gonna end up.
[00:05:16] Very cool. So, this is again just a regular old piece of calculator that we started on. It's in master, I just made a new branch.