- Overview
- Transcript
4.1 An Overview of Flux
If you’re not really sure what Flux is, don’t worry: in this lesson we’ll take a look at the Flux architecture, and I’ll explain how it fits into a React application.
Related Links
1.Getting Started2 lessons, 03:51
1.1Introduction00:57
1.2Application Demo02:54
2.Project Setup3 lessons, 20:58
2.1Setting Up a Gulpfile10:02
2.2Creating an Index Page05:45
2.3Starting the Server05:11
3.Server-Side Code6 lessons, 53:00
3.1User Accounts Overview07:23
3.2Configuring Passport08:55
3.3Installing Middleware05:21
3.4Writing the Login Template06:14
3.5Writing Login Routes19:23
3.6Creating the Chirps API05:44
4.The Client Side16 lessons, 2:43:53
4.1An Overview of Flux06:00
4.2Creating Constants and Actions16:22
4.3Writing the Store Creator14:13
4.4Creating the Chirp Store12:59
4.5Writing the App Component07:16
4.6Creating the Chirp Input Component17:55
4.7Creating the Chirp List Component10:31
4.8Creating the Chirp Box12:46
4.9Creating the User Store07:52
4.10Creating the User List Component16:12
4.11Creating the Follow Button13:51
4.12Sorting Stores02:13
4.13Creating Navigation03:13
4.14Creating the User Profile11:59
4.15Writing Store Mixins07:47
4.16Doing Server Polling02:44
5.Conclusion1 lesson, 00:29
5.1Conclusion00:29
4.1 An Overview of Flux
In this project we're going to be using Flux. Now if you haven't used Flux before you might not understand exactly what it is. So we're gonna look at that in this lesson. Flux is an application architecture designed by Facebook. Now it isn't a library and it isn't a framework. The simplest way that I've found to think about Flux is to think about it as an alternative to the MVC architecture pattern. We're all familiar with MVC. You've probably used a bunch of different MVC style libraries like Backbone or Ember or Angular. All of these libraries use the MVC architecture ideas to differing degrees, and they're certainly not all the same. They all have their own unique set of features. And so it's the same thing with Flux. Flux is an application architecture, so it's a pattern for connecting components to build an application. However, there are several different libraries that actually implement these patterns. And there are already quite a few of them. For example, there's Fluxxor, there's Flummox, there's Fluxible, there's Alt, there's Refluxjs and there's Redux. And of course that could be a little confusing, since they all kind of take their name based on the letters in the word flux. However, there's actually also one more which is the one we're actually going to be using in this course. And that is an implementation that Facebook themselves created. Now, I don't think that it's fair to say that that is the one true version of Flux or that every other Flux variation work just the way the Facebook one does, it's the one of the ways the Flux could be implemented. And, in fact, it's a very, very bare bones way. Most of those other libraries that I just mentioned have a lot of helper functions and stuff that makes it easier to build Flux applications with much less work. However, in this course, we're going to be using the original Facebook Flux library. So that is what Flux is, but the next question you might have is how exactly is Flux different from MVC, what are the components that you are expected to have, and what is the flow of data? Well, here on the Flux website you can see that we have this chart here on the page that explains actions and dispatchers. You can see here that everything kind of starts with an action. An action takes place, usually with some kind of data or something. And that action is sent through a dispatcher and we only have one dispatcher object for our whole application. And you can think of it kind of like a publish and subscribe system. Except actions don't really have names in the same way that events in a publish and subscribe system do. So everyone who subscribes to the dispatcher will receive all the actions that they can then decide whether or not they want to use them. However, these actions go into the dispatcher and will have the store or perhaps other places, as we'll see in another diagram in just a second, listening for those actions. When the action occurs, it usually has some data along with it. And the store is the place where you store data on the client side. You can kind of think of it as a model for backbone, or something like that. It's not exactly the same. However, it's a little bit comparable, if you're familiar with backbone. Basically, the store is where any data, any kind of state or other information that you need Is stored on the client side. Now, the views are then rendered based on whatever that data is. So, the views will be watching for changes in the store and if the store changes in some way, the view will update itself. Now, as you know, in this course, we're going to be using React as our view system. However, it doesn't have to be React. That's just what we're choosing to use. And that's something that's important to know. Since there are so many tutorials that combined Flux and React, it's easy to think that, well if I'm using the Flux pattern I have to use React as my view library. That's not true at all. You could use other view libraries instead if you wanted. However, we are going to use React, because Flux and React do work together quite nicely. Now, any changes to our application usually occur because of some interaction that the user themselves initiates in some way. For example, in our application they'll be typing some text into a text box and then clicking the Chirp button. In that case, we will have an action occur and that action will go back to the dispatcher. And come back through the store and then when the store updates with that data the view will see that and it will rerender to show the new Chirp that our user just made. This is one of the most important things about the Flux pattern, the unidirectional data flow. The data is only ever flowing in one way from the view or perhaps some other way Into the dispatcher, then to the store, then to the view, and around like that. Now you might be wondering, where does the server side fit into this model? Well, on the React website, there's another chart that I think explains this much better. The web API that you see over here on the left side of the diagram is our server side backend. That's the Chirps API that we've created. If we were thinking about this in terms of our application. On the front end we're gonna create a little Utils library that will interact with that API. But then notice that Utils library interacts with what this chart is calling Action Creators. Basically that means that the actions that flow into the dispatcher could come from the User Interactions as we saw in our previous chart, however they could also come from data coming from the server. So if we use the same example again, down here in the bottom in the blue square we have our views. And this is where the user may write a new Chirp. And when they click the Chirp button, an action may occur. And instead of that action going directly to the store it may go to the web API utils. First, and that Chirp will be stored on the web server. Then that Chirp will come back and we'll say, yes we've successfully saved it. So now, we can go ahead and add it to our client's site store, and then display it to the user. Of course that will happen all very quickly and pretty much instantaneously from the users perspective, however that unidirectional flow of data is again what makes this a Flux application. So that is a basic look at the Flux pattern that we'll be implementing in this application. Now I understand if it doesn't completely make sense just yet because I've just thrown a bunch of theory at you. However, as we go through these lessons I think all of the ideas at Flux should come into focus.