 I'm Jasim, I work at ID device where we build some fancy stuff. You'll get to know the details later. So this is a talk about flux and how we, as a two and a half front end people team, actually migrated a large-ish YU app to a flux-based stuff. And the lessons we learned and the stories behind it. There's a bit of react in it, but this is not a reactor. We'll only cover the absolute minimum react bits to understand the flux bits of it. Before I go to the demo, this is a 35 minute talk with 81 slides and over 200 lines of code. But I need, so I need to hurry, no bullshit, no meta. I hope you'll have a list of 10 things I learned from this talk by the end of it. So let's get there. So all good. Catch up and if I'm going too slow, I mean too fast, let me know. So if I have a small demo to show, what are we going to build today? I'm going to show you guys how to build a small app, a very small app of a simple, your conventional web app. There's a list of users. You can create a user. There's a list of teams where a whole bunch of users belong to a team and you can click on a team and it shows you the members of the team and stuff like that. You can create a team, add a bunch of users to it and the typical things. That's a sweet, simple app. I'm going to tell you, I'm going to work through this whole story of how we actually build KICAS web apps today and all sorts of things like that. Ready? People, come on. Right? There you go. So I hope you'll learn a lot of good stuff out of this and this is going to be KICAS. So that's that. So the first question I ask is like, what's wrong with MVC, man? We've been doing this for like five years. We have done a lot of stuff in it, a lot of apps. What's wrong with it, you know? You're just, are you throwing new stuff for the sake of throwing new stuff? No. So I'm not going to repeat what's already said. So there's this, you go to the typical flux thing. There's a default talk there, the talk which introduced flux and Jing does a KICAS talk on why this is not MVC and how this contrasts and stuff. So we are not going to go into that. So, and this is opinionated. This is not the best way to do flux apps. This is how we did it. So you're free to do whatever you want, take the good parts of it, throw the bad parts of it, no hard feelings. There you go, let's get started. So what's flux about? Flux throw away the concepts of MVC for a unidirectional data flow. So in MVC apps, we are very used to the notion of models and models managing your data. Most of the times, a single model represents a row in your database, which is very close to the idea of ORMs. So you have these models there, a lot of them, and in the case of that, you'll have a user model, then you'll have a user collection maintaining a whole lot of users, then you'll have a team model, team list, team collection, some way of remotely hooking up a bunch of a user collection into a team and all sorts of weirdities. Now you have those complicated model relationships and then you have even more complicated rendering logic where you have models and then models are doing like 350 even changes, name change, team change, team adder, that adder, what not. So how many things that's a bad idea though? No one, really, how many have written apps of that sort? So as of now, I work at a database, before this around like a year or two back, I was working as a freelancer and I was working for this British firm, they were doing a YouTube-ish thing. So they were working on a, so I was part of the team which built a web app. So it had like 250 buttons and like a super complicated model. So the model would fire off like 30 events every second, volume change, that change, this change. So you have like these hundreds of micro event listeners listening for like all sorts of events and then updating. And this is like a mess. I mean, six months down the line, I could not understand my code at all. So I was there, so when this was there, I'm like, oh my God, this is the thing I always wanted, like how could I miss this sort of thing? So if you have been there, I hope this resonates. But otherwise too, I hope you learn some sort of good. So what is flux about? Flux is, this is your primary mental model. This is much simpler than models and views and all sort of arrows. So you have actions, dispatchers, stores and views. We'll go into the details of each of it and how that helps. So first of all, actions. What are actions? Actions are the messages that go through the system. So and they all have a type and a data. So this would be an example, a simple action where you'd like, let's say, hello meta refresh and it's an action with some payload and a type which says new message. Type is a simple string. Everyone catching up? People? Wake up. I don't want to do the Superman's Spider-Man thing again. Really? God. So yeah. So every action would contain a type and a payload. So the only necessary bit is a type part and the payload is optional. A payload could be anything, anyhow you design it. So this would be an action. Stick to the actions, let's move on to the next step. What's a dispatcher? So if you go back to this picture, you have a whole lot of actions and actions propagate through the system. And you have multiple stores. So dispatchers are the things that send the action to wherever they need to go. So it's a central broker that sends all the actions to where they belong, right? And the dispatcher is actually a very simple code. It's a 50 lines of code, Chota library from Facebook. So we went with that. So as I said, this is probably not the best way to do it, but this is how we do it. So this is a bit of an experience story as well. And so it's like, oh, that sounds like PubZip. How many know about PubZip? Everyone, right? So how is this different from a PubZip, right? This is the old model we know. So you have actions which are like your old model messages. Now we have a fancy new name called dispatcher for your old PubZip. How is this different, right? So one of the fundamental differences is that you don't subscribe to a particular kind of event. You subscribe to everything, like you subscribe to every action out there. And every store that's subscribed will get every action. And so is that? And the most exciting thing about this is that every action is synchronous. And now it doesn't make sense, but we'll see the details. And you're going to be like, whoa, that's cool. Soon, in like 10 minutes. So how do you actually use dispatchers? So you give a function to a dispatcher and for every, this is it. 200 lines of code. How many programmers here? I guess? Way curve, it's code, read through it, understand it, kick ass. So by the way, the slides are up on, is this visible? So it's up on slides.com slash jesseemabad.flux. So if you really want to see it on your phone or computer, please go ahead, because I am blind. I can't see this from there, though. So I understand you guys. So you would give off a function to a dispatcher, and the dispatcher would call this for every action that goes through dispatcher. So this looks a bit like PubZip, but we'll see the differences, though. So you would give it out, and the argument would, the function would get one argument, which is the payload that is fired off. And that payload will have a type attribute. So the function you get can do its own actions, depending on the particular type. So you'll subscribe a function somewhere, and somewhere else in your app, you can fire off an event saying that dispatcher.dispatch, new message, hello meta refresh. This could be anywhere. And again, that's all we need about it. Moving forward, let's talk about stores. What are stores? For us, stores, anyone use immutable.js? Anyone? Anyone done function programming, immutable values, resonating somewhere? Oh, cool. So immutable.js is like this little tiny library from Facebook, where you actually have immutable values. A kikia stock, one of the best frontend talks I've ever seen. It's by a guy called Lee Byron. Totally, totally, totally recommending it. So a store is close to the backbone models and stores, but with differences. So for us, a store is a thin wrapper around immutable.js. If you don't know what immutable.js is already, think of it as just a small way to hold apps in state. We'll see a small example, and we'll see that, though. Stores hold all the data, as well as state. So in case of the user list, it holds the user list. It holds the team's list. It's close to your models and collections, but they also hold state. So am I actually keeping that dialog box open, or any of those states you can keep in a store? This is where we actually start to see the benefits of it. Stores are stateful, but not asynchronous. So you don't have any sort of callbacks, or actions, or promises, or anything like that. They're super simple. They're just holding state. You put stuff into it. You get started off with it. All synchronous, no complexities. Very simple. Stores listen to actions. This is where we kind of go into the philosophical bits of flux. Stores don't mutate themselves. You put stuff into it. You get stuff out of it. Nothing more, nothing less. Stores don't mutate. They're very simple KV stores sort of models. They listen to actions from the dispatcher. And when they can actually do something based on the action they get, and once they have the action, they emit out a change event. Am I going to do first? Right? I would say half of the crowd would agree. Yeah, but I have this little philosophy that if something can be better explained by a readme, it should be a readme. It should not be a talk. So I would not do a talk which says, the immutable JS, these are the four APS, these are the things you would do it in. The thing is that a readme can do better. I'm too fast for some people. I'm too slow for some people. I cannot make everybody happy. So readme is the best thing. So I go to conferences. Someone would talk about backbone.js. Then I would go to the backbone.js.org, pick up the readme, and go through it at my own pace. I'm like passively listening to the stuff. But that's what I do. So the thing is, by the end of the talk, you'll remember half of the things I said. You'll have a vague idea of what fluxes. And then you can go back to your home, go through the four readme's, and understand the bits of it at your own pace. But so what's the value of a talk? You get the big picture idea, and you know that someone else is actually building it, and they're having a good time with it. So for us, oh man, this was like God's end. Like no more complexities of the traditional backbone, YUI, whatever. This is beautiful. Accordza is went by a huge small factor. Everyone's happy about it. This is a good talk. So that's that. So back to that. Stores listen to the actions. So at some point, I have to go back. So eventually, at the end of 35 minutes, you'll start to make sense. So hold on, hold on, be brave, be bold. So stores listen to the dispatcher for the events, and they emit changes. And for our implementation, you need something called an item store, an index store, which you can think of as your simple models and collections. Again, moving forward, what's a store? Again, don't be scared by code. There's a lot of it coming today. So what do stores do? Stores are instantiated by a specification and a dispatcher callback. The same dispatcher callback I said about the dispatcher. So when you start off a dispatcher, you give it a function, and that function is dispatched on every possible action that goes through. So stores need to get all the actions from the dispatcher. So stores have a callback, and stores have a simple specification along with them. So what do you do? So this is an approximate prototype of a store. And so this is how you would actually make a store. So for the user store, you need some sort of API to get all the users out of the store so I can actually show that pretty pretty little list. So how would you do that? So one of the key ideas, as I said, is that stores are synchronous. How many have ever written a simple Ajax-based web request, got the data, and showed a list out of it? How many? Everyone? OK, let's stop for a minute and talk about that. So when you actually write a jQuery.get slash users list and then pre-printing it, it's not a synchronous code. You're not saying users equal to get users and then using the value. You're giving a callback there. So if you're ever planning to, I'll go into the testing bits of this. One of the key reasons to do this is testability. If you're ever thinking of testing this, you can't test this externally without a whole lot more callbacks. I can't write a very simple test saying, users equal to get users, users dot show list, and then assert on it and see that, oh, it's actually rendered a user. I cannot do that. Because in very simple terms, it's not a synchronous data model. And I think, as users, we tend to think synchronously. If we are thinking asynchronously, that's because that's what computers do. It's not that we inherently think asynchronously. So stores, in that matter, greatly simplifies things. There is no asynchronous bits at all. You ask for data. If it's got data, it returns that to you. Else, it just says that, no, I don't have data. Deal with it. That's all. So this is where we start to see this model becoming simpler. Your models did hold asynchronous state in them. Your stores don't. So you're already seeing how things start to become simpler. So we are trying to move all your state in, rather than your state of the app being scattered around a different whole lot of places. What are we trying to achieve? We are trying to control the state. We are trying to control the asynchronous behavior. So we are moving the state to one place. We are moving the synchronous bits to one place. And everything else becomes super simple, pure functions. So this is how you typically implement something like a store. Still awake? Still with me? Yeah. So if you look at that top thing, I think you can. OK, let's look at Get By ID. If I ever ask for a user store dot Get By ID 42 to get a user by ID 42, what do we do? We say if I don't have the user, I'll return this fancy magic object with a state pending. And that's it. If I don't have the user or else, I'll fire off onto something called useractions.get. So this is, again, one of the terminologies that Facebook implemented called Action Creators. We looked into that, too. And before that, if you go back to the store again, it's OK if you don't get the whole thing. It took us a couple of weeks to actually go through the whole thing. Digest it. It's mostly not my work. It's my colleague's work. So he kind of taught us everything and eventually picked up. So a store, as I said, a store needs to have its own specification, its own functions, like Get By ID, Get Uses, or whatnot. And then it would have a function which runs as a callback on every possible action. So this is the specification for the user store. And this is the function that's going to be called on every action. So it's a very simple thing. So anytime as if you go back to the first slide I showed, this is an action. It could be fired from, for now, let's say, any part of the system. So you can arbitrarily fire an action from somewhere called New Message. And that can be used by your application in interesting ways. Look at that. Try to remember that thing. What is an action? Action's got a type and some payload. Now, going forward, you could fire that first action from anywhere in the system. And the store can actually use it. So if I fire an action which says user gets success, that means I actually successfully fetched a list of users from the server. No state so far. So if I actually get that, my user store can listen to it, take the data, put into itself, and fire an image change. Now the thing is you don't have state anywhere in your store. It stores are listening to an external message. And when they actually get the external message, they modify themself and then say, now I changed. So your stores tend to be simpler. I'll show a simple unit test of how you test this. And when you see that, you're like, whoa, that's actually a nice idea. So going forward, so if I ever get something called a user gets success, that means my server came back with a whole lot of users. Somehow, magically, I'll immediately show that. I'll put that into my local state and say, I changed. How do you do that? Sorry for the scroll bars. Facebook added one more thing called a user actions. This is where we actually model all our asynchronous page. This is the only thing in all of your app which is not synchronous. One place to hold all of your Netto, K-Pace, Asynchronousity, and stuff like that. You could hypothetically just mock this one thing and test everything in your app. So I wanted to do a cool movie sort of demo, but not there yet. Someday I'll show it. So this is the one place where you do the asynchronous thing. So looking at that, you would do your typical, look at that part, the get users thing. That's your traditional Ajax call way. That's what we are used to. So at that place, you would, so the get users, so if I don't have the, going back here, if someone asked the store for data and the store don't have the data it wanted to, it would fire off this useractions.get, right? This one, and how is that implemented? So useractions.get would immediately fire off an action. The top one dispatcher.dispatch user get pending. This is a message, the same thing we put in the first slide. So now you're starting to see these changes, right? I'm asking for asynchronous data. The moment I ask for it, I immediately fire off a message saying that, okay, now I'm trying to fetch the data. And then it does the traditional Ajax call which we are familiar. And it might eventually fire a success or a failure, right? How is this important? You'll see soon. So before that, so this lets you do things like someone could listen for the user get pending event, put out a fancy loading bar on top or whatnot, and then when you actually have the data, put them into stores and show the data or you can eventually handle the success or failures. Still with me? Still with me? Anyone? I guess the final big picture will make sense. Hold on, hold on, right? There's a lot more on stores, but there's only so much you can cover on 30 minutes. So just gonna quickly walk through. It's not completely models and collections. They do a lot more. So the typical use case of using models and collections is like a subset. Models, stores don't modify themselves. They just listen on actions from the dispatcher. They don't modify themselves. They're simple key value store sort of behavior. Stores don't mutate themselves. They don't have Ajax callbacks or anything happening in them. They listen to actions. They do things based on the actions payload and then they say, okay, I changed. Nothing more than that. It's super simple. They're singleton, so if you have like 20 views in your app all asking for the data, you already have the data. I'll look into, come to talk about singleton's leader. Stores, let's skip that for now. Okay, now going back to the original picture. Flux talks about the four pieces. So I'm sure you have a vague idea of what stores are now. Hold on. So the last part of the equation is the views. Let's quickly go through the views and get back. So views, we went with react. It might not be the best way to do it, but we went with react. Views are almost stateless. They take some current state, they give out an HTML, nothing more than that. This is probably gonna be the simplest UI code you ever wrote. Views are synchronous. You don't have no XHR, no callbacks, no promises, nothing. No more fancy terms, it's pretty simple. Views get the data from stores and listen for changes. This is where we see the interesting bits though. So the user list page you see, everyone remember was the app right? So the user list page you see is a view which gets the data from the stores. It's gonna say, use a store, give me all the data. Give me all the data I want so I can show it all. Right? And it just takes the state and shows out an HTML. Let's see that. How many don't react? How many went for the react workshop? Right? No, a few. So again, so I need to do a bit of it. React is this very interesting framework from Facebook. Thinking about it, it's a huge anti-pattern though. So I've been doing Frontend and JS and everything for around four years. So over four years you tend to have these little, little good practices. You know, don't put CSS inside your JavaScript. Don't put HTML inside your JavaScript. Who knows about that? Right? So don't put HTML in JavaScript. So if you ever had somebody who were doing like string concatenation in this JavaScript and updating things like, dude, that's so bad. You know, you don't do that. Then you think about it. Why is it bad to do that? Right? Like because the Frontend God said so. Paul Irish came in a talk and said, you can't do that. So we tend to blindly believe that. And then Facebook comes with React. And it's like a massive anti-pattern. Then you're like, whoa, what is this? So it's just around a year old. So just out of curiosity, I went into the hack and use the original hack and use discussion and the original Reddit discussion. And the top 20 comments are all negative. This is a bad idea. This is a bad idea. What not? First of all, what a year, everyone's talking about it. It's so hard to ignore. Every other fancy website is moving to Flux and React. SoundCloud, Airbnb, everyone even we moved in, right? So things that look like anti-pattern are the first time that some people put a lot of thought into it, it, it, it, think, think, think. And then they're like, okay, this actually makes sense. This is what happened with React. And the same thing is happening in Flux too. The first time you read it, this is like a massive anti-pattern. Oh, I know that's a bad practice. I know this is a bad practice. Then we really think, why is it a bad practice? Then it kind of starts to make sense. That's what happened with React story, though. So React is interesting in the sense that you write these so-called views and React as a library manage the views for you. It puts, you know, if you have a user list sort of something, it renders it, puts it to the right place, updates on all itself. Your first day will be like, oh, this is all magic. And the second day, you're like, oh my God, why was this not there like 20 years back sort of thing? So let's look at a simple React view. I'm not gonna go into the details. But you would make a view by saying React.createclass. And it gives you those super long verbose, ugly looking function names like component will mount, component did update, and things like that. So one of the things, as I said, React does is React manages the lifecycle of the views by itself. So you don't have to do things like when the page loads, take this guy, do this Ajax call, get the data, render it, and put it in this box. You don't have to do that anymore. React does that for you. It sounds like magic. Yeah, a bit of magic is there, but it's fine. So what it gives you is it gives you these small little hooks you can use to modify the behavior, React, saying that do something when the component loads up, do something when the component goes down, and things like that. Let's say you have this simple clock. Okay, wake up. Okay, now think, I have this problem for you. Let's say I have this simple timer widget or what not. Really think, okay, I need solutions. Give me a good answer and you'll get a T-shirt, the same thing. Okay, let's say I have this simple timer widget. I have this countdown timer. So I go to this particular page, I want this countdown timer to start. Right, all that. So what do I do? On page load, start a timer, you know, reduce a value, render it every second. When do you stop the timer? How do you ever stop? Anyone done this before? Anyone ever wrote a JavaScript timer? How do you stop it? When do you stop it? What? Yeah, shoot, answer. Go ahead, yeah. I mean, half of the people are sleeping, so wake up and give an answer. Yeah, sure. Drone? Yeah, shoot. Yeah, shoot. A stop button. A stop button, a timer to stop. No, there's no stop. Okay, so you want to stop this timer? I'll rephrase. This is a single page app. You go into one tab, you see a countdown timer, you go to other tab. No stop buttons, nothing. Okay, so basically there are service workers or web workers, I think. So they basically get delays or doesn't work when you switch tabs. So when you come back. Let's say you have 250 buttons. You have 250 other ways to get out. Okay, so this is one way out. So he's saying put a hook on whatever ways to get out. That's not gonna work if you have like 200 things. No one else with an answer. Yeah, shoot. On the click handler for the tab, you would basically say go stop timer. That's what I said. Let's say you have like 200 other. Then you would want to emit an event that the, you know. Emit an event from where? Yeah, emit all sorts of events. I mean, like whatever happened and the timer listened to all of the events that should cause it to stop the timer. There you go. How many even listeners will you write? Hundreds, right? So one of the ugliest ways you can do it is put a timer and in every, put a timer and every time, put a timer, simple timer, and every time you try to update, see if the actual DOM element that was supposed to show your content is still there. And if it is there, update it and keep the timer running. And if that guy is not there, stop the timer. That means basically if I somehow moved from a page to another page, stop the timer, right? Anyone done? We had hacks like that? Oh yeah, another one. So okay, so he gets a T-shirt though. Yeah, so it's actually ugly. If you think about it, it's ugly. Every one second you're checking if the DOM element is there. It's like a massive performance hit and things like that. No offense, I was hoping that more people would have weird hacks like this and everybody was like, okay, that makes sense. Okay, my question failed though. But still, whatever. So what this react components let you do that, this is actually good. The day you actually start writing it, who answered it? There you go, get a T-shirt though. So this actually, if you think about it, very simple, right? That when I put a component into my app, do this. When I take the view down, do this. This tends to work pretty well in a team too because you have like standard places to put things. You have less argument with your teammates and everything tends to be same. So just read that though. Again, back to the stuff. So the moment I put my user list view into my page, so I have this little function called getStateFromStores, obvious name, right? So when I actually put my component into the DOM, I'm gonna call that function called getStateFromStores. And what is it gonna do? It's gonna get all the users from our user list order. So this is the function. UserListStore.getAll, right? And going forward, you have these two little methods, component did mount and component did unmount. So when the component mount, that means when I put the component into the page, start listening to the store for changes. And when I push it out, stop listening for changes. This is like that simple. I mean, can it be simpler than that? So you have this little view, put it into the page, start listening for stores, you take it out, you stop listening for stores, and you have this little function called getStateFromStores, which gets the statement stores. Clear? Sounds better than the dirty timer hack I said. So how would you do this? The same case of timer, in a component did mount, start a timer, in component did unmount, just stop the timer, as simple as that. So, questions? No, right? Yeah, yeah? Now I'm simply modified and removed, check for that time being removed. I would think that's what they're doing internally here also. Yeah, so that's, his ask is like, if React is doing that for you, React is probably doing that kind of dirty checks in your, in the library itself, right? There are two reasons to it. Don't be like that. Yeah, yeah, I get the general notion. He is that if you had to do the dirty checks, it's probably that React is doing the dirty checks. There are two things to it. One, it's a library, it's not your headache anymore. When you are building your app, when you are just concentrating on your app, you can concentrate on that. You don't have to deal with that. The other thing, you are like the obvious performance issues and stuff. It's a very largely used library. So, even if it's a hack, the hack tends to be the best hack available. So, you get the library event. At least it's not your code to maintain or your hack to maintain, right? React might be, we'll look into that soon. So, going back to that, so we have this simple user list page and what I'm gonna do is, when I go to the page, I get all this data from the stores and the time I mount the component, I start listening the store for more changes and when I move out, I stop listening to the changes, right? And this is how you'd write a render. The first time I saw this, this is probably around seven or eight months back when we were considering React. What does this look like? It's JavaScript but there is HTML inside your JavaScript, right? And this is not even valid JavaScript anymore because this is a syntax error, right? So, again, thinking about it, it's simple. The issue with your templating systems like handlebars or whatnot is that you try to keep your template simple but you still have loops in your template and weird logic or whatnot. So, what's the point of things like handlebars when you're anyway doing complicated things? So, this is how you would write a user list render. So, you have that users loop through the users, make a table row, show it in and this works as simple as that but there's a catch. So, if you go back, I did a user list store.getall. What happens if the data is not there, right? This code is gonna blow up because my users is not an array, I can't map over it. No one caught it. So, we'll come back to why that works too, right? So, there's a bit of hack and there's a bit of goodness in React too. Every React component comes with two things called view state and view props. This is where I see it as a good design decision for Facebook where you have, if a view needs to maintain its own state, it'll have a property called this dot state and if a view gets a bunch of properties passed down from the top, it's this dot props. It's a little nitty gritty detail. I just needed that to be there so I can continue it out. So, this is something you can get better from a readme. So, I just popping it up there. So, now the thing is the original diagram had only the first four things there. Now, if you remember the app, we had a user create button, right? So, you have your actions in the system originating from we don't know where yet. Then you have dispatchers dispatching all your actions to the necessary stores. Then you have your views listening to the store and getting data from stores and actually showing out a list for you, right? So, this is like a one directional thing. Now, when you have something like a user create form, you need to actually do something about it, right? How do you actually do that? So, the last part of the piece is views can give actions back to the system. So, this is where we tend to move away from the MVC where views don't update the models. Views just fire off actions. So, how do you ever do something like, again, scroll bus? So, let's say you ever have a user create button or whatnot. So, you would have something, your typical on submit handler, you have a form and on submit, I have to, what I do is, we do something like user actions dot update. User actions is the same thing that we used in the store to get the data. Where's the store? So, when the store don't have data, we showed this, right? User actions dot get, and this is the user actions. Your views call the same user actions to actually handle the data changes. On submit, some, when your user submit the form, we can call the user actions to say, user dot create. Get the big picture, though. You don't have state in your views anymore, right? This thing needs to maintain the absolute minimum state. This is synchronous. You're not doing an age I call in your view anymore. You have a bit of state to maintain what's in the form. Did I actually start typing and a bit of that? But you don't have any asynchronicity in your form anymore. Your stores are simple. They are key value stores. No asynchronicity knows the minimum state to require. Your views are even simpler. Now, you start to see a pattern coming up there. You try to move all your asynchronous behavior into one piece of code called user actions or what Facebook calls it, action creators, right? So you don't have state propagated in all of your app. So this is not state less programming. It's more like state aware programming and asynchronicity aware programming. Rather than scattering them everywhere around, you tend to localize it. Unless you have written like large apps which really screwed up your brain and had a hard time. This is like a moment of cry, you know, wiping off tears. If you've been there, you know it sort of thing. So this is one of the best parts about the architecture where you have to admit that there is state. Any web app is stateful. Any web app will have asynchronous calls. You cannot ignore it. It's what the platform gives us and it's gonna be always there. What Flux does, and this is the place where Flux tend to shine. It tries to control all the behavior and localize it to particular states. Going forward, your view will fire off an action saying that useractions.create a user and it's done. It's not dealing with that state anymore, it's done. So your views tend to become simpler and testable. But your actions need to do your old behavior of things like, you know, it would immediately fire off an action saying that someone's trying to create a user synchronously and then it would do your asynchronous callback and eventually it would fire off a success or a failure. Right? So we'll see that though. So there's a bit more on it. There's a bit of, a lot of story about dependent stores but I think I'll just skip that. If you really wanna know, come talk to us. We have like a lot of story on dependent stores. I'll skip that. Okay, so where, why you would all of do this? This comes into testing. This is probably one of the biggest reasons to switch to flocks. Your code tends to become simpler and they tend to become testable. So React gives you a thing called a small utility called testutils which lets you do a test. Is this visible? I'm sure this is where I hope everything start to make sense, right? So if you have a computer, open up the slide. If you have a phone, try to squint your eyes and read through this, right? So what is this about? Raise your hand if you've ever written a front-end unit test. 10% itch. Raise your hand if you want to write front-end unit test and you don't know where to start. God damn it, yes. Finally I am getting the right audience for this talk, like. Thank you. Why are you not writing front-end test today? What's your reason to, right? Answers, you got a T-shirt for a good answer? Yeah. Really hard to mock the browser, yes? Abstractions, okay. Don't mock the browser, run it in the browser. Why are you not running it in the browser? Yes, you should give a question, man. How do you simulate user actions? This is where we're going, awesome. And what is your comment again, once more? Abstractions are leaky. What do you mean, abstractions are leaky? I mean, in React, these problems are solved that everything is component-based and they're nested inside each other. Yeah. So when we're developing applications in things other than React, this is not the case and normally things start getting more and more messy. Yeah, so I hope I'll convince you to switch. It's very difficult to test unit-test things. Exactly, so his point is that it's very difficult to test your front-end code as units because they're always coupled with other things. How would you ever test a back-bonus view because it's coupled with your model, there is a state in it, there is a synchronicity in it. When you try to take something like render user, assert on it, it's not possible because there's so much state and so much complexity and so much coupling in it. The best you can ever do is functional or acceptance level of test with something like Selenium and if anyone has ever written Selenium it's the last thing you wanna do. I'd rather hang myself to death before I write Selenium test. It's just that ugly. So let's look at the approach though. Everything I said today, if you're taking one thing out of it, is that flux apps tend to become, try to, I mean, it's at least closer towards a testing model. So this is, we'll spend like five minutes there. So going back though, the last slide said, Facebook released a library called Jest. J-E-S-T for testing though. Again, this is how we did it. This is how I did it. I tried to go through Jest. I could not agree to half of the things like magic mocking and this and that. So I'm like, leave it all. Let's go back to the plain old Mocha testing and this is it. So anyone done ever Mocha testing or something like that? So Mocha gives you this little function called describe and it. Describe is just a way to group test. So when you have a describe block, it pretty prints that and shows it in a block and it is like one simple test. So first thing, first test says, I'm testing my user list and there is a renders a loading page test. How do you ever test this in a back bonus app though? What I'm gonna do is I'm gonna, if you go back to my view, I'm gonna say user list is equal to react class, right? So that user list is my view component, right? Remember the name and what I'm gonna do is I'm gonna use this little utility from react on test utils, yeah, this guy, test utils.render into document. It's just a tiny, okay, it's just a tiny little function which takes things and renders it to the DOM so you can actually run a bunch of assets on it. So take the user list. I just put it as a string as a quick hack. It's actually just user list. If I put it as a string, my syntax highlighting used to get really bad. So I just put that. So render my user list into a user list. There's this little function called get DOM node. So you do node.dom node and you get the actual DOM node, right? And now you write your plain old expectations on it and it's synchronous. You're not, so if you ever had to do this in a conventional app, right? You actually have to do something like sleeping there. Sleep for five seconds. Hope that my Ajax called came back and is doing things. We are not doing that anymore. Everything is synchronous. So get a user list, render it to the DOM, immediately query it and expect the text content inside that to be loading. This works. Nothing. No, no, smiley faces saying that when could you ever write a test like this? It actually works. And the first time I wrote it, I'm like, wow. I mean, it took me, so I'm coding front end for around four, four and a half years. So it took me around four and a half years to get there and the first time I actually got there I was like so happy. It's like a moment of joy, right? How do you write something like actually do an Ajax call, come back and expect that? So there's a bit of catch here. I'll show that. So now how would I show that? Let an Ajax call come back and show it. Now I want to test that it actually has got a list of users, right? Just fire off an action. Just fire off an action. This is my test mock data. Just fire off an action which says user gets success, right? And then again query your DOM node and expect to see one item there. So this helps because now you're like totally decoupled. You're not mocking a model and then doing what not. It's one global dispatcher. You fire off a mock action which looks like your Ajax call back and now you can test it. You can go through that. You can take this to an extreme. I have to admit that we are still doing the baby steps of testing. And the first time we actually want to do a serious job with our front end testing because it's extremely painful business and this looks promising to me. Anyone having a similar feeling? Some, some. Am I convincing? At least some that it's possible to write test. Why? Because this tends to be synchronous. Where did the asynchronous bits go? This one line, this dispatcher.fire that used to be the asynchronous thing in our entire app, right? That used to be my network call. I just mocked my network call by it saying dispatcher.fire. Now everything synchronous. Run through it, no magic, done it. So, almost, yeah. So, the some lessons, so this is the big picture. The some lessons we learned. We could cut down a whole lot of calls because stores are singletons. We had like excellent caching. So we could actually cut down a whole lot of network calls in some particular cases. It's testable to a large extent. For the first time we are actually seeing it happen and we're really excited about it. One lesson to take away. Your asynchronous bits tend to be localized. So, as said, in my testing code I did one line of mock and you can actually do this. Your state tend to get localized to stores and that's also a huge benefit because your views are like dead simple to write, dead simple to test. Views are mostly stateless. They are synchronous. No more Ajax, no more callback, no more promises, none of those. This is like a tiny little demo I wanted to show you but it didn't completely work out, I had to admit it. What I wanted to do is load up the demo app, fire off these actions in order and it would have actually played, it would have walked through the app like a movie. I would have been able to do a demo by just doing a next, next, next. I just didn't get time. I got this idea like way too late yesterday else I would have actually showed this. You can actually have a demo which is like totally just firing off the right actions in order. No need of a DOM, no need of a network call, nothing should have worked but someday. If you really want to know how to do it, come talk to us. And it gives you detailed analytics which is actually current's idea. It's like if you actually capture every action that goes through the system and fire off to something like mixed panels, you get kick ass analytics. The user actually did this, user did that. Everything's an action. You get brilliant analytics for the first time. So these are the some of the lessons we learned. There's a lot more to it but yeah, things like optimistic UI updates, excellent caching, there's a lot of immutable JS goodness. Please go check it out, immutable JS. If not flux, at least immutable JS because that's something you can pull into your project whatever it is. There's a lot of react JS goodness. We implemented good things with something what we call has enough detail. Sometimes you are actually able to completely ignore network calls if your view don't need network call. We added some say in error handling for the first time. We have some good routing patterns which current did and there you go. That's a big picture. This is your mental model. You have actions which are like your gateway into the system. You have stores listening for them and doing appropriate actions. You have dispatchers sending their actions to every possible store out there and then you have your views showing up what you want. And that's all folks. We probably have one question or one question. I guess you'll have 10 things I learned from a talk. I hope so. At least a big picture. Oh yeah. This is like a tip of an iceberg if you want to come to us. The react is here at the same time as AngularJS is here and most of the feature is same here and there and even the testing, whatever it's saying, unit test ecosystem is very good in Angular as well. So when we are choosing one framework and what like you have already worked on ReactJS. So what is your suggestion for AngularJS and ReactJS? I have to admit that I'm not very familiar with Angular. I've only done bits of it. But if you look at it, right, flux is in my abstract, I said flux is not a library, it's a specification. It's an idea of doing things. So maybe there are ways to do this in Angular too without pulling in React. Flux don't need React. So the idea is you tend to localize your state somewhere. You tend to localize your asynchronous bit somewhere and then send messages to everything. I'm sure you can actually do this with Angular if you really want to. Yeah, because Angular, because I am spending some time and found like unit testing and to end testing and all these ecosystem is very good. Here, whatever you're saying, the data model and services stuff and all is very good in Angular, that's what. Okay, I'll look into that. Yeah, thank you.