This course has been updated! We now recommend you take the State Management with Redux & MobX course.
Transcript from the "Flux Conclusion and Review" Lesson
[00:00:01]
>> Steve Kinney: Right, and now we've effectively implemented the flux pattern. And again, I'm gonna say this one more time cuz it is the important part. If you're like, hey, I just added like six files and a bunch of complexity. Originally everything started at the top of my component and I passed it down.
[00:00:13] Now, I have actions in a file and I have a store in a file and I have all these event listeners. Yeah, you do, right? And that was the trade off that you made to not have to pass things down six levels, right? Now, you can like literally pull in this store and the actions, and hook them up to any component in that tree.
[00:00:30] But you've paid a price, you paid the price of complexity, right? You've paid the price of things being harder, right? So it's not necessarily a slam dunk that you always know that you want to do this, right? But if you give yourself the regular container pattern, you can start with state.
[00:00:51] And then okay, this tree is getting out of control, right? You've given yourself all the hooks into your application to switch over to flux, or to redox, or to mildx, right? And that's the important part, using those patterns we saw before, right? We're gonna look at all these libraries.
[00:01:07] And they're very cool, and I want you to have an understanding of them. But like if you come out with like a core thing, it's close to the patterns that we saw in the lightning round, right? Because once you implement those patterns in how you architect your application, you give yourself the ability to switch.
[00:01:21] Like redox is so six months ago, I'm switching to mildx. You give yourself the hooks to do that, versus baking it deep into your application. All right, we're gonna switch gears for a second. And now we're gonna kinda look at some very scientific charts, right? Because we looked at code, we saw it in action.
[00:01:38] Normally people show you the charts and then do all that. My hope is that we can see some of it in action, see where it looks in the code, now pull back and look at it at a higher level and then we'll jump back in. It took me several times to wrap my head around flux.
[00:01:55] My goal is to give it to you in three within an hour. It's very ambitious. But we'll get a chance to play around with it as well. Because the next one we'll do the same pattern. Were I'm just gonna give you a little set of instructions and let you try to get inside of jet setter, and we'll do it together.
[00:02:12] Lets switch back over to our slides.
>> Steve Kinney: So I told you about that flux library, this is that complicated chart that everyone shows everyone. It's a circle. The problem with a circle is that it's not really clear on where you start, which is why we showed it in the code a little bit.
[00:02:33] So we can kind of see actions go into the dispatcher, which send stuff to the store, which send stuff to the views where the user can click on stuff. And the circle of life continues, right. There is a part here where the action creator, it might need to go make a network request, or hook in to some web api, right?
[00:02:52] That can happen as we get ready that object to send it along. But starting with this chart for me, has been universally unhelpful, [LAUGH] right? Yeah, it wasn't until I did it a few times that it made sense. So, let's talk about this step by step. Looking at the whole chart, not very helpful.
[00:03:13] So I drew my own very scientific looking ones that are very official. This is a dispatcher, this is that first part in the circle. This is the first thing that we wrote. You can have multiple stores, right? And they are objects that exist. To hook them up, you need to register them with the dispatcher, right?
[00:03:35] So they're like, hey, I'm a store, dispatcher, I care about what you have to say. Please, when you receive actions, can you please let me know. This fresh is like, I tell everyone everything, I don't keep secrets, everyone finds out everything from me. So the store that uses App Dispatcher.Register, does he like I want to subscribe to your newsletter, and they will start getting dispatcher weekly, which will send them the actions that it hears.
[00:04:02]
>> Steve Kinney: We have all these presentational components cuz we're all about the presentational component. Maybe we have some high order components. If that's a current user store, maybe there's a higher order component called with current user that hooks into that store and passes it to whatever presentational component that it gets.
[00:04:18] But we have these presentational components that are super testable. And we eventually want to whether through a higher component, a container component, or through render props, we want to listen to the store. Right, again, I am a huge advocate of you breaking out the presentational part from the container part, cuz it lets you change your mind later, and reuse it in different parts of your application.
[00:04:38] So we'll start listening to the store, And the storm will start admitting those change events. Hey I changed, Hey I changed. This is the new thing. I changed. Right, and they can be like okay what's the new stage of the world. They get that as props. The UI changes.
[00:04:53] The user touches stuff as they are want to do. Right? As they do that, they trigger click events and change events and all of those things. Right? Those get sent to the action creators and where do the action creators send them?
>> Steve Kinney: To the dispatcher. Right? And here we have the circle.
[00:05:12] Now one of the things we were talking about thinking in react was what kind of data flows do we have in react?
>> Speaker 2: Direction
>> Steve Kinney: One direction, unidirectional, right? And so the data is only flowing one way, right? We have some registration happening, like hey I care about you, start sending me stuff.
[00:05:32] But the data is still only going dispatcher to store, store to views, user clicks something, that goes to an action creator that then goes to the dispatcher and the circle continues. Alright, so we keep that one way unidirectional data flow, we just remove it from the component tree.
[00:05:49] This could be anywhere. We could put this at the very bottom. We could put it at the top. It doesn't matter because it floats outside of your component hierarchy tree, alright these views ideally have trees, they have sub components right? But we can have viewers subscribe directly to the stores, again, we make a dispatcher.
[00:06:09] An action creator is simply a function that dispatches an object right to the dispatcher. Stores register themselves with the dispatcher, they decide what kind of, they listen to every single action and decide whether or not they care. If not of these conditionals are met then the store doesn't do anything.
[00:06:29] It is like I don't care about the thing you just told me about. But if it does care, go ahead and do something, right? One thing I like you to notice is that I've changed some of the nouns in this one. The dispatch is the same. I have like an add new item.
[00:06:45] Action, I have this add new at this ItemStore, sounds like I'm gonna have an application coming up that has items. And maybe they get updated, or removed, or packed, or unpacked, I don't know, I definitely don't have the next line in front of me. So our store contains models, it registers itself with the dispatcher and receives the actions.
[00:07:08] An action again is the minimal state. We don't need to figure out everything, if it's incremental, we just want to know the new value. If it's a new item we just need the item. We don't need everything. Remember we said before in the thinking and react section, it's that when possible we want to derive state.
[00:07:23] We don't want to figure everything out. And so this keeps the pattern of what is the minimal possible information that you need? There's no set state, you just basically, action is the only way you get to change anything. Simplest possible action. You can add additional information, you don't need to.
[00:07:45]
>> Steve Kinney: When it does hit the store, if that store cares about it, it will do the thing but you have to emit the change event because that's the only way that the view find out. It's everything needs to either ask to be told about something or tell the next thing.
[00:07:57] This isn't like I just create objects and they just magically know about each other. I wish, right, Everyone of these things needs to communicate with each other. Right, and you need to like build those things. It doesn't just happen magically by having this. Your views listen for the change events.
[00:08:15] Right? I usually like to do it on component did mount and component will on mount. Remember we said earlier, where like it might be very like update items. Don't put that on state cuz it's part of this component. If you don't render it, it doesn't go on state.
[00:08:27] This would be on the instance. So, that instance of the component would have an update item's
>> Steve Kinney: Property on it. Cool.
>> Steve Kinney: And then when the user does something, we can go ahead and, look, it's a new item component. I don't know where this came from. It's almost like we're going to need this soon.
[00:08:49] That will just call add item,which is an action creator. Which will tell the dispatcher, which will tell the store, which will update the view. The only thing we do when our handles submit is prevent the default from refreshing the page, because that is bad. Because it's a form and if you hit enter your page is going to go away because of the web.
[00:09:08] And we'll pass the values though and then it'll reset the form.