This course has been updated! We now recommend you take the Complete Intro to React, v8 course.

Check out a free preview of the full Complete Introduction to React (feat. Redux and React Router) course:
The "Flux" Lesson is part of the full, Complete Introduction to React (feat. Redux and React Router) course featured in this preview video. Here's what you'd learn in this lesson:

Flux is an application architecture pattern for building client-side web applications. It emphasizes a unidirectional data flow which compliments React. Brian shares a diagram of the Flux data flow and highlights the use of a ‘store’ which is responsible for providing data to a view component.

Get Unlimited Access Now

Transcript from the "Flux" Lesson

>> [MUSIC]

>> Brian Holt: So what is Redux? Well most of us are familiar with Flux in some capacity right? If you've heard of React for the most part of within the same couple sentences you're gonna say the word flux as well. I'm personally of the opinion, like I'm gonna give this big disclaimer, we're gonna be using Redux, but this is definitely taking a sledgehammer to a small nail problem.

[00:00:24] For the most part all the principles I've shown you so far with React is enough to make a small app. In other words for this small of an app, there's no reason we should be using anything like Redux. It's too overpowering it's too much of a big tool for a small tool job.

[00:00:38] React in and of itself is actually fairly good at marshalling your state to where should be. And you use Redux once your state starts growing into a bigger mess to handle and you need it to be more manageable and more available. So let's talk about Flux a little bit.

[00:00:55] Because kinda the evolution of things is there was Flux first and then Elm kinda took that the Elm language, I don't know if you've heard of Elm. But Elm's a really cool, new functional language to write interfaces. I'm really excited about is doing a Elm class within, what, a month or so?

>> Speaker 2: Yeah, April 14th and 15th.
>> Brian Holt: From Richard Feldman who's like awesome teacher, awesome guy. Bless you. So definitely something to keep an eye out for. So there was Flux, Elm took Flux and just like really simplified it, made it easier to interact with. Made it like a really cool thing.

[00:01:36] And then Dan Abramov who we've mentioned several times during the course of this course. He's the guy that did hot module reload, he also works a bit on React router sometimes I think as well. He had decided, well, I won't give you the whole back story. But the basic gist is he took the Elm architecture and kind of ported that as well to React and just plain JavaScript.

[00:01:59] And the end result of that is Redux. So it's interesting to know like what Flux is and then what Redux kind of riffed on flux is. So the basic idea is, we have this one way data flow, right? That we've been dealing with a lot in React, right?

[00:02:18] That you have this parent has a bunch of data and then it gives some of its data down to the child, and that child gives some of its data down the child, right? So it's just props passing down props passing down props, right? That's kind of the idea.

[00:02:31] So data flows down but it never flows up. The child never hands any data up to the parent, it's always data flowing down, right? And then you have these callback functions that the child can say, hey, something happened. And it's up to the parent to change something and then re-hand it back down to the child.

[00:02:45] But there's one source of truth and it's at the parent level. So they kind of took this another step further with Flux. So Flux you have a data store right? In fact I think I, I didn't put it in here, but do I have a Flux diagram?
>> Brian Holt: React, right?

[00:03:08] I'm sure there's lots of, please Facebook don't fail me now. You're failing me. Okay.
>> Brian Holt: This is the one I wanna show you, so you basically have a store, right? And I think that a store makes sense, it's where we actually keep all of our data, right? And then the the store passes all of it's data that is needed to the view, right, and then the view displays it.

[00:03:36] But now something needs to happen right, like we need to change something, right, like for our search term, right. We need to be able to update from HO to HOU, right? There's state changing over time. So what the view does is that it's kind of the same idea of like hey, something happened over here.

[00:03:54] And then it's up to basically the store to be able to handle that. So I type U this fires off an action, right? The action goes to what's called the dispatcher and the dispatcher is just a really fancy term for a function that just dispatches to other function, right?

[00:04:12] So, it comes in and it says, I see an action type of update search term. So I'm gonna dispatch that to this other function that's actually gonna go into the store and update it, right? So you're just firing off actions, the actions go to the dispatcher, the dispatcher dispatches that to another function, and that function updates the store, right.

[00:04:30] And then the store passes that data back to the view. And then the view is just waiting for more input to send off actions. So it's this very close tight loop that the view sends up actions. Those actions get dispatched, update the store, they get back to the view.

[00:04:45] And it's just this loop over and over and over again. So what's nice about this is it's very well defined. So if there's a breakdown in the process then it usually becomes very obvious, very quickly where the breakdown is. I don't know if any of you have worked much with like backbone or model-view-controllers or Angular for that matter or I'm sure Ember has much the same problem.

[00:05:08] There's so many cross dependencies and so many things that modify other things, that if something breaks you just don't have any clue how it broke, right, and that's really a problem. By tightening this loop and making this loop very well defined, it's very easy to follow these actions around.

[00:05:25] So that's kind of the basic idea, this is a Flux. This is not Redux,this is Flux, right? And if if this speaks to you, feel free to just run with Flux and there's plenty of people that do, that choose to not do Redux and choose to go with Flux.

[00:05:41] And there's plenty of Flux implementations out there. There's Flummox there's Alt, I think Nuclear is another popular one. There's a bunch of these other Flux like ideas out there. But as you can see this is actually a fairly simple. Like there's not really much going on here, like your dispatcher's really thin.

[00:06:02] The stores are really just big objects and actions are just objects as well. They're objects that have an action type and a value and that's it. In other words it's not very hard to implement Flux. You can probably do it within 50 lines of code. Any questions on Flux, because I'm gonna build on Flux when I talk about Redux.

>> Speaker 3: So if you're building a smaller app would you want to use Flux over Redux?
>> Brian Holt: I would say they carry the same amount of weight.
>> Speaker 3: Okay.
>> Brian Holt: I would say if I'm building a small app, I'd just stick with vanilla React, but that's a great question.

>> Brian Holt: Redux is as lightweight as Flux is, in other words.
>> Brian Holt: Does this make sense? I mean, I realize we're still in the abstract, we haven't written any code yet. And so if it's not concrete yet it's going to get concrete very quickly, hopefully. [LAUGH]