 Alright, so I'm Gabbo and this is David and we're going to be talking about flux architecture and also we're going to be talking about some flux, which is basically an implementation that we wrote, a library that we wrote for using flux inside of AngularJS. Now we won't be getting too deep into the Angular part. This is more about how you can use the flux architecture in whatever language or whatever part of the stack you're in, actually. So with that said, what is flux and where does it come from? So basically flux is a pattern that Facebook came up with not too long ago, like I would say around the year, and that emerged from them using React. So React is a JavaScript library that is just a view layer and this library is basically very unidirectional, so everything that comes in, there's just one way data binding and when you're using this pattern or this library, like when they were creating Instagram, they saw this pattern emerge and they decided to formalize it and call it flux. And then the main thing about it is that it's a pattern not a framework, so you can use it anywhere, like I said earlier. And then the unidirectional part is the really, really important part about flux, like the name flux is Latin for flow, so it's all about having one direction and if you're doing two-way data binding and stuff like that, in a way that is mutating your models, you're doing it wrong. So that being said, this pattern is not completely new. It's basically variations on PubSub, Messaging, and CQRS, which I always get wrong, Command Query Responsibility Segregation. So this pattern, like when we used it for Angular, the way it came out was Angular 1.3 came out and I saw that we had some features that made directives, Angular directives, or you could call it views for those that don't know. So I saw that we could use it in a way that was very reactive, so it's all very component-based, there's no non-mutation from the top, so it just started, I started using it that way just to bring in the cool things about React that I liked into Angular. I wasn't trying to make Angular behave exactly like React, but I wanted to take the good parts and bring them into Angular. And then what happened was I started seeing that naturally this flux pattern started showing up in different scenarios. And I was telling David, oh, this is really cool, like I want to see if I can come up with some sort of bastardization of flux, and David was like, no, we should just go full flux and try to put in all the pieces and just make it like the formal pattern. And then after a million arguments and discussions, we came out with song flux, which is the library. So that said, I'm going to be showing you a lot of rectangles and arrows. I'll be going over mostly over the patterns and how does flux fit, like what are the squares that make up flux, and then I'll let David go into the nitty-gritty part. So actually, and a little precursor to your talk about MVC, usually we use, what? So if you look at the small talk version of MVC, it looks very one-directional. You have your model which populates your view, and then you have a user that creates a user interaction, and then that tells the controller to do something on the model, and then the model updates the view. So you have this, what you could almost say it's very, you know, it looks like what you'll see in flux later. And the problem is that that's what we do with small talk, or people do with small talk. I've never personally done it. But that's not what we do today. In contemporary MVC, we put it all in one flat line. And here in this slide, I kept the same arrows. So now I have those same arrows, they're going in one direction. So obviously my view can tell the controller to change the model, and then the controller can change the model, but my model can't tell the view what to show, or the controller can't tell the view what the model has. So what you usually do is you add that extra arrowhead on that line. This is, there's nothing wrong with this, by the way. I think this is pretty nice, it's elegant. The problem is that you do have to have some, you have to be strict about how you write your code, and constantly make sure that you're refactoring, because the moment you start adding complexity, it can get pretty gnarly. That's this next slide, where you can literally see wires being crossed. If I start adding more, you can see that there's a lot of different things going on, and it's a lot harder to tell what is coming from where, and what is doing what. For example here, I have the view in the middle. I have two controllers affecting that view. Now that might sound like, oh, that's not something you do in web development, that happens a lot. Like, I've done it, I'm not proud of it. I've done it, and the first thing I have to do is write it to do, and go back and change that, because if I leave it like that, it's going to make it a lot harder to add more features to the application. And then you have, in this little scenario, you have two controllers affecting one model, and the model affects two controllers. So the problem with that is, if the one controller does something, how do you need to make sure you have the mechanisms for that model to tell the other controller, hey, I updated myself. You need to have some sort of eventing, and you've got to wire it on a per instance basis, and that makes it really, really tough to scale up. So you definitely, with NBC, as good as it is, you definitely have to have that discipline on making sure everything is as many straight lines as possible. So if we go to Flux, how does all these rectangles and arrows change? Well, first I'm going to take away the complexity, because keep it simple, and then I'll bring it back and show you. And we have our controller, and I'm going to change it to what's called a store. Now, a store is not a controller, even although sometimes I'll catch myself calling it a controller, but it's not. A store just stores your model, and then tells the view what information to display, and it has the ability to do operations on your model. That is all the store does. So that being said, now that we have that our store, it tells the view what to do, we take away the arrowhead, let me show it back, that arrowhead here, we take that away, because the store always tells the view what to do. The view never goes back to the store and says, hey, you need to do something. So since the store then also has the model, we take that away, and now we only have these two squares, or rectangles. And then so now that we have these two simple pieces with one direction, how does the view then go and tell the store that it needs to change? Well, it has to take what's called a round trip, and the first thing it does is creates an action. So the view then creates this action that says, this is what you need to do, like for example, if you have a user that you need to update the details, like you say, update users or user, and you give it the user details, and that's what the action contains, that's it. So now you have this action, you gotta send it somewhere. So you don't send it back to the store, because if you do, basically you're then making this two directional arrow again. That's not good. So you need to pass it somewhere to update the store. So what that happens, that happens through what's called a dispatcher. So the dispatcher takes actions and sends them off to all the stores. The dispatcher is pretty dumb, all it does is it takes this action and to any stores that are subscribed to it, it will then send off the action data. So obviously then the dispatcher tells the store, hey, your user details got updated, update yourself, it changes the data, and tells the view to update itself. So in a more concrete way to see this, oh, wrong slide, all right. So if I add complexity, well, I'll talk about the other part later. If I add complexity in this example, you see that it still goes in a circle. I can add more stores, I can add as many things as I want, and it'll still always be circles. And then the dispatcher, you usually have one. Facebook is pretty adamant about having one dispatcher per application. Us, when we did some flux, we were like, we'll give you the ability to create more than one, because why not? But we do try, you should try to only have one. This is your central, this is like your bottleneck, but it's not really a bottleneck, I don't know how to, so yeah, this is the other slide I wanted to get at, the flux to do. So how does a to-do work in flux? So if you have your to-do view, and you wanna create a new view, so how does that work? You first have your user interaction, which is user clicks, hey, give me a new to-do, and then that goes down to then create that action data, create that action with the data. So this create to do action is created with that to do information. So obviously this needs to be sent to the dispatcher, and the dispatcher receives it. So now the dispatcher has this create to do action. It says, okay, any stores that are subscribed to this type of action, I got a new one you need to update yourself. So the to-do store gets the create to do action, and it has, for example, the title or whatever. It adds the to-do to the to-do list array, for example. And then it says, hey, views, any views that are subscribed to me, you need to, I updated myself, so you need to get this data. So it emits that event, and then the to-do view gets that new to-do list, and then updates itself, and then you have in your list that new to-do. So that is the long way of how it goes. And if we were gonna look at it in a more like coding code way, this is almost Angular code, took a little bit of some shortcuts. So this is, if I'm gonna save a user in the more MVVM pattern, you get the details, and then you map that to your, let's say this user thing is what's called an Angular resource. So you just hit save, and it'll send it back to the server. So you need to map your details from your view back to this model, and then click save, and then send it off to the server and save. And that's pretty simple. And then how would you do that with Flux? You actually have less code, because all this logic would actually live in the store. You send off that action and not worry about it. The view just does what it needs to do. Just sends out that action, and then the store does what it needs to do, and then the view just updates itself. So the difference is if we start adding complexity. So let's say the user got updated from the server, not by user interaction, what do you do then? So now you have to map the details that you got into the model. And now you have, you can see there's some sort of code repetition to a certain degree, you have to map things back and forth, and it's a lot more work. Well, with Flux, what you do is nothing. Because the store took care of updating, it's giving you your view model. The store took care of everything. The view got created itself or re-rendered itself, so it got the data again on construction. And that's why it's like, the views are just that simple. Now, if you're looking at this example, you might be asking, and you know a little bit of Angular, you might be asking why didn't I use two-way data binding? And that is a good point to bring up. It does alleviate code repetition because now you have your two-way data binding. But the problem is, now if I have my view here and it's got two-way data binding, and now let's say this are my user details over here, and then I have a user list, and I start changing the user details here. The name in the list of the preview is gonna change, and you're getting that side effect with that two-way data binding. That's bad because you're sharing state, and that's always a very bad thing to have in your application. So you're gonna end up having that duplicate view model. So you make sure that things don't affect the other side of your app unless you hit that Save button. When you also have that mutation, you have what I call stealth bugs. So if this can affect the model and this can affect the model and these two views are live, you don't know where the bug is coming from. Whereas if you're using Flux, it's pretty simple. It's gonna be in one of three places. It's either gonna be the store, the actions, or your view. So if you look at your store, if the data is coming in correctly and it's coming out correctly, then you know it's not your actions and it's not your store. So then the data is correct, so it's just a display. So you just look at your view and maybe you have some view logic that's saying, hey, you find the bug in there. And that's what makes Flux so amazing because you can then find everything pretty easily. And you don't have to know the system. So if you're going into that shared mutation NBC state and you have a large scale system, you're gonna have to know all the moving parts to know where to look. Whereas with Flux, you just gotta know the pattern and you just know, okay, so these are my stores. This is where the data is coming in. Where is it being sent next? And it's gonna be one of the places of the views and then if not, it's gonna be one of my actions. It's that simple. Now with that being said, I'm not saying NBC is bad. It's just, there are different scenarios for different situations where you want to use these tools. And David's gonna get more into that, but this is something that's really good that you really want to have in your tool set. So, yeah. But David, take it over now. For the first half and all of our code examples, I only have my phone. I don't have fancy note cards, sorry. So I'm gonna have to be doing both to see what I'm doing next. And so, Gabbo just showed you kind of the 101. If you go to the Facebook Flux page, that's kind of what they'll go over. I just wanted to kind of take another chance to reiterate and ruminate on what some of these different pieces are meant to encapsulate and meant to do. A store, like Gabbo said, he motivated it by taking the model and the controller, the controller telling the view what to update, the model having this reference to all the data and knows how to save it. And kind of merging them into this one thing, which kind of makes sense. Kind of pull away the view update logic out of the controller and pull the model synchronization issues. Put them into one thing called a store that just understands how to deal with all of your data thing. And now you have a really great single source of truth. You have one place where you know that this is exactly what the user model is going to be. You don't care that there is possibly a disconnect between the input field on the view and the actual memory value that you have in the browser, versus what's being sent over the wire for your rest interface. You've got one source of truth that is the store and anything that the browser touches, it's going to go through the store and you know that, you've really focused that responsibility. And you have lost something though, you now can't have the controller updating the view. Well, you don't need the controller updating the view anymore because we have the store emitting mutation events. And suddenly we have this great little messaging system where any number of components can jump on, listen to events, any number of other stores. If they needed to, could jump on and listen to events. So you're building a chat application and you have various threads for your various chats. Your threads themselves will have a number of unread messages count. And when they increment or decrement, if my messages have been read, they'll emit an event, my little chat bar will see that and it'll change its value from ten unread messages to no unread messages. Congratulations, you've cut up on your inbox. And at the same time, the overall inbox store will also be listening to the same PubSub system. And now I can say, hey, you have one fewer thread that you need to pay attention to and it'll reduce your total unread thread count. So having these single sources of truth really simplifies. It kind of shifts that MVC triangle a little bit and really simplifies some of these pieces. Views, we also, again, we've shifted kind of the other. We've also shifted back a little bit. Instead of the view only being our display and our rendering itself, the Java days of swing tables or even our HTML DOM. This is going to be a little bit more intelligent now. It is going to be responsible for some of its own logic. Let's say you have a mildly complex wizard that walks people through a four or five step configuration. That's only one piece of data on the back end. That's only one piece of data in your store. But the actual state for moving between pieces, between your four fields of your wizard, your four wizard pages, is managed in the component itself because that really, the step that they're on in the wizard doesn't map one to one to the data model that you have. So by moving that back, your view gets a little bit more intelligent. We actually start calling it a component, not a view. On the other hand, that greater intelligence is much less repeated, much more focused, and much more single point of responsibility. Of course, you do need that last piece. Instead of our view model constantly updating or two way data binding, I type something into my input field that's immediately updated in my model. And as soon as I've stopped typing for two seconds, the model goes off and fires a rest save request. I don't get that anymore, so we need this way to get data back into our system. And we do it with another messaging channel, in this case, we call them actions. The view has finished whatever it wants to do. The user has indicated that something else is going to happen, save my new contacts, send my chat message. This action will get generated and sent into the dispatcher for the dispatcher to manage. And I like to view these actions, and I haven't really seen anyone else do this. So take this part with a grain of salt. But I like to view these actions as a user request for change. And as the user is encouraging your application to go to a different state. There might be a very valid reason to not allow that. The database connection might be out of date, or the thread might be out of date, and so all the people have left the chat room so it doesn't make sense to do this action. But most cases where normally you'd have this method called this action will be much more decoupled and much more flexible in sending itself through. We do want one last little piece, and this is in smaller letters because you don't manage this yourself. The dispatcher is this core kernel of an idea that manages this all together. It's really just a fancy pub sub bus. That's all it is. Facebook tries to make it more complicated in a lot of their documentation, but you just send something in with the string tag and it sends it out to whoever is listening on the string tag. A little bit of discussion as to whether you want one dispatcher per application. I prefer one dispatcher per unified module. This means that all of your chat widgets are going to be, if you think about Google Gmail, you've got all of your chat, or Facebook as well, you've got your chat functionality sidebar with your contacts list and the chats along the bottom, and then you've got the main inbox, your main wall feed along your back end. I would separate those into two modules. If for some reason you needed to send a message between them, usually you're going to be within your own ecosystem, but every now and then you can fire a message off to the other ecosystem saying, in inbox for example, open a new message composing field in the chat bar usually when you go to edit the more rich text editor. So that's kind of an interesting examination. One last little piece to point out here is that the dispatcher is a little bit smarter than a regular pub sub in that Facebook has a concept called waits for, which allows you to declare within your store asynchronous dependencies between receiving actions. So back to the earlier example we had where we had a thread store and an unread thread store where the unread thread store keeps track of how many unread threads we have. When you get a new message coming in, the unread thread store will say, before you let me take care of the new message, go ahead and pass it off to the actual thread store so that I can put it in the right place, update the right counters, and then I will take over. So that's a really interesting place that you can have a variation on a traditional pub sub that is very useful. And the dispatcher does also manage that only one dispatch is going to happen at a time, which means that you know that only one action will be processed at a time, which means that you won't ever end up changing an input field one place, watching the model change, that model fires an event, that triggers another update over here, and so then we have this mutation cascade where all of our models are listening to all of our other models, and everybody's trying to update all of the same model at the same time because they're all trying to keep track of the same things. We stop that, all of those pieces can fire their own actions, which will get triggered in their own dispatch cycles, but we're only ever going to have one thing happen at a time, and if we ever put a break point in there, we only get one unit of flow going through our application, makes debugging very, very easy when you get some pretty complex interactions going on. Song Flux is a library, like we said. It's specifically a southern, overgone, angular flux, we're very clever. It's an angular module, you can drop it in. It gives you the dispatcher, and we have some documentation on some little utilities, angular utilities that'll kind of flesh out that ecosystem, make that a little bit easier to work with. Catch up on my notes. Where are we at on my notes here? Do we have some of these? Oh, right, this is Song Flux. So the Song Flux dispatcher, again, it's the same thing that the Flux guys, that the Facebook guys have, you can get multiple dispatchers, you get your dispatchers lazily. If you're working with angular, this is kind of a really fun way to pull it on. Facebook does something where your actions are registered via a string. We don't like that, because you end up with some really ugly event handlers that have some weird switch statements in them. We've actually found that it works very well, where the action will be an action constructor, a function that you can instantiate with a JavaScript new keyword, and then you get this great instance of a constructor. You can use the constructor itself as your management, as your key in the PubSub. It works really well. It's a lot of fun. Oops, our stores. If you're familiar with angular, there is a way to create a controller on a module. Our stores work the same way, and they provide a little bit of utility. It's very, the store itself has a method to just quickly register based off of one of those action controllers that we described a minute ago. Not every dispatch needs to go through a store, but again, this just provides some one-liner utilities. This.register, action name, this.prototypeMethod.bind this. And you've got your handler just all nice and easily contained. And our code that we've used this way looks pretty nice, if I may say so. Actions, like I said, and action is just a constructor object. Usually, it is a simple wrapper around a plain JavaScript object. Function, newMessageAction takes a message object, this.message equals constructorMessage, and you dispatch that along. They also do have a little bit of benefit in that we can attach a dispatch method to them, which will provide a little bit of boiler, reduce a little bit of boilerplate in that you can just pass it right into your dispatcher without actually needing to go through and telling it which module it's dispatching to because it knows from the context of where it was created. Views that we do, again, are inspired by React. Angular has this concept of scope, which is a second prototype chain for your view layer, which lets you have a parent-child relationship between views. We issue that. It's very powerful to the point of being too powerful, where you can very easily make a brittle application. Instead, we make every component its own little self-contained thing. I'm passing in data, passing out data, passing in data via store observations and mutation events, passing out data by creating a new action. And we actually go so far as to use a component, define a new thing called a component. Again, for those of you who use Angular in-depth, this is a variation on a directive where we isolate our scope. We bind all of our scope properties to our controller directly. The controller itself is also a constructor function that can be instantiated. It has its prototype chain to create any methods that you want for any activity. This is the thing that is responsible for creating and dispatching events. The instance of the constructor within the component is exposed always as state. This is an idiom thing. It doesn't have to be state. We use state as an idiom. So whenever you're looking at a view template, if you see a binding to state.whatever, you know that's coming from the controller. Again, this lets you implicitly create a view variable that will let you, for the wizard page, maintain which page of the wizard you're on without having to go full bore into a constructor method or a full-on observation of a data model. Again, that's an idiom that we've found very useful, and you'll see more examples of that in some of our documentation online. And finally, you can just use either your inline template or a template URL if you're bindling. We've seen all this before. We really have. The Angular stuff is specific to Angular Shore, but this is just another way to do the small talk model view controller back when every arrow was one direction. Two-way data binding is really strong. It's really powerful. It's almost too powerful for what we're capable of handling on large teams where you start getting a lot of churn. A lot of people online will say, that's just CQRS, Command-Query Responsibility Segregation. Yeah, it is. It's just PubSub. It's just another way to do it. It's just another variation on this. Like I said, there are some nice idioms that we've found and enjoyed with the Angular side of things. The waits for is a nice idiom for enforcing asynchronous dependencies. A lot of ideas from reactive programming. Basically, no one has a direct reference to anybody else. You just say, inject the store that I want, and I will listen to whatever I got injected. If it's a test mock, if that's the actual instance. If the view is backed by a REST connection or a web socket, we don't care. That happens in one place. Everything else is events and PubSub, and we can just do what we want. So again, why do we choose this variation on MVC? It scales very nicely. It's very self-contained. It's a higher barrier to start building an app, but once you're used to the pattern, it's such a useful pattern that once you start seeing it, you can really easily jump in and be effective on using that pattern. Both of us have gone off and built apps for a week over here, a week over there, jumped onto the other person's code, and immediately seen where everything just falls into place, where everything is supposed to go. You're listening to events, which are by definition self-documenting if I describe which event I'm listening to. And it just focuses everything in these few one, two, three very focused places of your application. Why is my store sending bad data back to the database? Drop a debugger in the store. Click, click, click. That's where the data got wrong. That's the line that's wrong. Fixed it. Moving on. We're done. No weird dependencies between anything. There are still really good times to not use flux, and this is definitely something that we think is important. If you're not larger than four or five views and one or two models, you're not going to see any benefit of this. You're going to spend more time setting up all of these PubSub dispatchers than you are actually writing your interaction code. So for a small application or for a small self-contained piece of code, probably don't use flux. Probably use MVVM or more traditional variations. On the one hand, it is, I think we have these. Yeah, it's pretty easy to add a new piece, but you have to add this piece in three places. So again, if you're not to the size where you need it, it might not necessarily be the best choice. It's a pattern. It's another tool. It works very well. We would implore you to go forth and think about maybe considering these ideas. Facebook wants them to be really hot. They're cool. They're great, but they're fine. These slides will be online. You can go on. Most of this, the precursor to this talk was a blog post that we wrote together. It's published on Medium. We have a sample app up on GitHub, and we'll add another couple of links to some other apps that we've built since we've written these slides to that. And is that the? Yeah. Finally, the library itself is on GitHub. And the easiest way is to MPM install SongFlux. The libraries themselves are in the disk folder. They're in the browser folder. So SongFlux, for those of you familiar with Node Modules, it'll be in NodeModules SongFlux slash browser slash songflux.js. So with that, thank you very much for your time. And does anybody have any questions? And does anybody have any questions?