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.