All right, so first lesson. What can go wrong will go wrong. Don't rely on your internet connection for your presentations. But we're just gonna go with it for now so like the fonts might look a little messed up and I think give it a couple of minutes and we should have a fix in place. But we're gonna go over some of the high level idea stuff first anyway. So hopefully we'll be good by the time we hit the first demo. So today we're gonna talk about reactive, component-based user interfaces, specifically using Facebook's React library. So my name's Ben. Obviously, I don't work at Facebook. I work here at Constant Contact. So I'm just talking about this today because I think it is like it's just a really incredibly powerful way to build UIs. So what are we gonna talk about today? So we'll do an introduction for those who don't know what React is. More importantly, the why bother. It's a great question to have to ask yourself. We're gonna go over a couple of React's big ideas. So it's not just a MeToo framework. It doesn't do the same things as other frameworks just in a different way. It truly introduces some unique things that aren't available anywhere else. And then we're gonna do some live coding slash, actually I'm just gonna show you some code. Because like I said, what can go wrong will go wrong as we have demonstrated. Awesome. All right. There we go. Font's working. Yay. All right. Okay, so everything comes down to performance too, right? Because that's the quickest way to just toss something aside. We'll address that concern. And then lastly, there's another big idea besides just like the rendering part of the UI. It also introduces some functional patterns.  It's sort of like the gateway drug into functional programming because you can use it in sort of the UIs and places that are familiar to you already. All right, so what is React? It's a component based view layer. So some people think of this as the V in MVC, right? It just cares about the view part. I think what you'll see as this presentation goes on hopefully is that it's a lot more powerful than that. That's sort of not doing it a lot of justice, but that's how some people use it. It's created by Facebook and Instagram. Obviously they're the same company now. And because of that, we get the compatibility with browsers back to like IE8, right? So we don't have to worry about a lot of those things. And the goal here is to create simple, easy to reason about user interfaces. Now that seems like such a high in the sky concept, but I think as we go through this, you'll see what I mean here, what that means. So who's using it? Obviously Facebook is, Instagram, the whole app is written in React. Khan Academy, they have like a large backbone application and they like to react so much and they got so many performance benefits out of it. They just removed all of their backbone views or started rewriting them one by one. And that's why some people say it's the V in MVC is because you can directly start replacing some parts of your application for performance reasons, right? Mozilla Firefox for panels, right? So I like this because it's not just about common UIs. This is a general purpose rendering library and they use it for their panel stuff. So Reddit, New York Times, this list is changing constantly. One of the more interesting ones is people are obviously no GitHub, anyone use the Atom editor, right? So it's kind of like Sublime for those who don't know or any of the text editor. That whole thing, that whole screen, this whole user interface that you're typing into constantly is done in React. So you've used it before, if you've liked anything on the internet, on Facebook, you've used React. So a couple of key points. These are sort of the main takeaways, the main problem points and what we're looking to address here. So DOM manipulation is painful, it is slow, and it is error prone. That is sort of the big idea that we're trying to, this is the problem we're trying to solve. They borrowed this idea from, I think it's 37 signals, right? And it's called just give it five minutes. So we're gonna look at the code. Some of it might not look super familiar if you're used to programming in a different way, but I promise you it'll only take five minutes. And then, so don't freak out. I know we're so used to doing the to-do MVC sort of evaluation where you look at it for 10 seconds and we immediately dismiss things. But I promise that, specifically for this last part, right? Because it exposes patterns that make our program simpler. And I think giving something five minutes to get that as a benefit is a pretty good win. I think we can agree with that. So, but in order to make these sort of frameworks realistic and solve real world problems, they've gotta be abstracted from the applications that have these problems to begin with, right? This is a big defining idea behind Rails, is it was built on realistic problems. And I think that's what, if you start using React, you'll see that they, they don't try to solve every problem, but what they do try to solve are the really super hard problems of these large interactive applications and solve it really well. So what are these problems?  That's what's to say pretty. Making good software is pretty hard, right? I think we can all agree with that. So let's go back a few years. Like why is it hard? This was me, I made up this year, but it's probably around this time where it seemed like asynchronous problems were like everywhere. That was everything. Race conditions in the browser, why doesn't this work? Oh, it's a race condition, you would tell your boss. And that's because asynchronous program in the browser was like kinda new or we were stretching the limits a little bit. Like this is when our architectural concerns were like, which jQuery plugin are we gonna use, right? And then so when we started building, you know, larger applications, we would just hit our head against these asynchronous problems. But I suggest, highly suggest going to Kyle Simpson's talk after lunch, because he's gonna talk in depth about all of these asynchronous tools that we have to solve these problems. But I don't think we have tools like that that help us deal with the state problem, right? So state, this state problem exists in all programming languages. It's not just in JavaScript. But I swear this is me every single day this year. Every bug that I get, it's no longer about async. It's about we have too much state and not just dealing with state, but specifically dealing with mutable state over time. Like that seems like a pretty strange concept too, but how many people get error reports or bug reports to say, just go to this page and refresh it. You'll see what the problem is. It's just usually not how it works, right? It's usually like you take eight user actions, right? And you're like, oh, well, I never thought that that combination of things would be used or it's hard to hit all of your use cases, right? So over time, the amount of possible states our application can be in is just growing exponentially. And this is really where we run into the problems of having unmaintainable software. So that's where the reactive part of this talk comes in. Now this is sort of a big loaded term. This is probably a little small for you, but this is a site called the Reactive Manifesto. I really suggest checking it out, but it's really in depth and we don't have time to cover all of it here today, but for our purposes, I wanna say, we're gonna consider reactive event-driven and responsive to state changes, right? So these are the two criteria that we're gonna try and hit. So event-driven in JavaScript that might seem redundant, right? I mean, some of the first things we have to learn to do in JavaScript is to do event handlers. The DOM is eventful. This is how we write programs. We'll talk a little bit about how that changes a little bit later, but we're gonna focus on this responsive to state changes now, right? Cause this is the big problem for me anyway. So let's talk about reactivity in the DOM, right? Because there's three different types of states at least that I can think of in our applications. There's state on the server, then there's state in like your client-side models, something like that. But there's a third state effect. We don't even think about the DOM as stateful, but it is, it's like the definition of stateful. And we've gotta keep, not only two, but we've gotta keep all three of those things in sync. And that's where this really becomes a problem. So react doesn't care about what doesn't, it doesn't try to solve the problem of syncing your server data with your models on the client. It assumes that we've already got some pretty good ways of doing that. What we're concerned about here is taking our models and serializing them into the DOM in a reliable way. So I stole this image from a guy in Brandon Hayes who gave like an amazing talk at RailsConf about refactoring towards Ember applications. And all of his same principles apply here. And actually you can watch this talk, which I highly suggest. And all of those things apply to react as well as Ember. They're not distinct, but this is important. No touching the DOM, we just can't do it. When we react to events and we find ourselves getting into those weird, funky states after eight actions, it's because we're touching the DOM. And we're doing it in an imperative way. And it just does not scale over time. You'll just, it's the source of all frustration. So reactivity in the DOM, we've already got a solution for this, right? So everyone remembers the first backbone or knockout application they wrote and how magical it felt when the DOM would update when you would just update your models, right? It was truly groundbreaking. But then we started pushing the envelope even more. We made our applications more stateful. And then we started to just run into some kind of problems, mostly around that touching the DOM too much. So what do we do? We double down. Let's throw everything we got at it. So we've got this thing called two-way data binding now. And this is huge in Ember and Angular right now. So is that it? Have we solved this problem? So it works very well. And I'm certainly, this is not an anti-data binding talk that would be pretty stupid because it does work very well, but you can't ignore that this is still happening, right? You can have all the two-way data binding you want. This does not go away. Complexity still exists. We're just throwing curtain over it and saying, don't worry about it. We'll take care of it for you. But what happens when that breaks down? You're gonna have to dive into that and try to figure out what's happening in your application. And I'm not making this up, right? This isn't me just trying to give persuasion for confidence talk. You don't have to read all of this, don't worry. But every week, the Angular core team has a meeting to talk about the problems that they're trying to solve, right? And in this one, one of the core developers, he brought up some points that we don't have, we don't yet have plans to solve some problems we see in large applications. In particular, how developers can reason about data flow within the application. Scope is a huge pile of shared state all over the application. And because of two-way data binding, it's not clear how the data flows because it can flow in all directions. This makes it hard to understand the application and understand the impact of model changes from one part of the app to a seemingly unrelated other part of the app. I think that summarizes a lot of the things that we see when we build large applications, right? And those guys, trust me, those guys know what they're talking about. They've been there. So how did we get here, right? This is Rails, but honestly, this could be anything. Consider this like just the HTTP, this is fetching static web pages. We never got into weird states here, right? When you would request a page, did you ever think in Rails or any other back and forth? Did you ever worry that? When the request gets here, an update's gonna happen and our data will be half done by the time it gets rendered down. That just doesn't happen, right? It works, everything flows one way instead of that sort of nest that we had before, right? So the request goes up. By the time it hits the back end, it takes a snapshot of the data, right? You get a copy of it. You don't get the actual thing. It merges that down into the view, it renders in your browser. If something changed in the middle of that pipeline, it does not matter. You received your snapshot. Things don't get into funny states. You just didn't worry about it. So that's great, but that wasn't very interactive, right? You had to reload the page. And I like this graphic, because you can imagine if you had an application that was changing so frequently in the back end, if you had turbofingers and you could command R, refresh your browser, like this is what it would look like if you had a static application, right? But what it was was predictable and reliable. And it might not demo well, but predictability and reliability in the long-term obviously matters. Like I don't think I have to sell you guys on that. So when you think about it though, this is really sort of how things render even in our applications now, right? So each frame, if you freeze it, everything's a discrete snapshot of state and time at that moment. So what if we could refresh the DOM on every frame? You've got, say, you've got a frame like that, it's just called turbofingers. And all it does is just constantly reload everything all the time. So that's the goal here, is we wanna get to the reliability of that model but have the front end look just as interactive as we can build in any of these other components, right? So that's the big idea behind React. Every time data changes in your application, it's like hitting refresh in a server rendered app. A big statement that probably means nothing to you right now. In this example, you don't need to know too much about it, but each node is just a part of your UI. Could be like a contact sidebar thing. And when you update the state, it uses set state, we'll talk about that. You don't need to know what that means, but if you're familiar with Angular Dirty Checking, what it does is it marks your whole components considered dirty, right? And then it will batch up these changes and then re-render just parts of the DOM that matter, right? So nothing changed over here, we don't need to re-render that. I like this analogy a little bit better, right? So it's like source control for your DOM. So think about source control, I'm gonna zoom in here so we can look at it. Imagine if source control did work like a sledgehammer, right? Imagine if you got into work and you did like, get fetch and you say show me what happened yesterday and it's like these files changed, okay? So what changed in those files, doesn't matter. It's just somebody changed some stuff, here's the new copy. That wouldn't be very useful, right? It knows not only which files changed, but which lines changed and not only that, but it knows in this particular example, this class changed from a loss to a gain and then you see this text changed, right? So it knows at a very fine level, it's like a scalpel as opposed to the sledgehammer. It can go in there and find the exact minimal amount of changes needed to go from one version of the file to the next and react as like that. That is sort of how the DOM diffing works. It is a very fine grained mechanism to be able to figure out the minimal amount of changes needed to bring your UI up to date with your data. So we're gonna look at a little example. This is just an animation for now, so don't worry about it too much. It's just gonna be a stock ticker, right? So you can picture this being part of your UI. As data flows in, it's automatically updates, so we're not doing any imperative DOM integration. We're just re-rendering every single time new data comes in to get that reliability factor. And do people know about, any of you guys know about mutation observers? Less than I thought, okay. So this is not a React thing. This is like a W3C browser tool. So it's a JavaScript API. What you do is you say, given this little div, right? Anytime anything changes in there, I want you to tell me about it, right? And so we're gonna record, and it tells you something was added, something was removed, text changed, blah, blah, blah. So you see these are the things that that API tells us. Great for troubleshooting and things like that. We're gonna use it to build a sledgehammer of a demo and the scalpel version, which is the React one. It will actually count the DOM mutations that happen so that we can see if React is actually making a difference or if it's just a bunch of talk or marketing. All right, so this is gonna be the sledgehammer. This is actually written in Backbone. All right, we started the application, see the stock transactions coming in and you see our DOM mutations happening over time. Blue is DOM additions, so new list items that are added to this ticker and black is DOM removals, right? And so we'll just take a look at the totals to keep things simple. We've got 166 added DOM nodes and 155 that were removed. And that's set to a 10 second timer. It's gonna stop automatically after that. So now we wanna see if our more surgical approach actually can have a difference, right? So this is the same exact UI written in React. And you'll notice at first, it looks like it has like a similar performance profile. We're going up at the pretty much the same rate. Our removals now come in once we hit 10, which is our max to display. And so this is over the same 10 second time span. If you remember it was like 165 before. Now we're looking at 19, 19 to nine, and that's with continually triggering refresh on there, because it's only gonna touch the very minimal parts that it cares about. So we're all developers here, right? So that's all well and good, but if it sucks the code in, you're not gonna wanna do it, right? So we're gonna look at what it takes to actually write this UI. At first, I'm just gonna take it from a high level. Nothing custom. We're just gonna have an image tag, right? And so we've got this command here, React up render component. It takes a component and then it takes a container to put it in. So we're just gonna overwrite the entire body tag. We're gonna take over the whole UI, but this could just be one tiny part of your app. Now, this is actually a video of me the first time I saw JSX, so this is gone. It was a few weeks ago, I got a haircut. We have HTML in our JavaScript, and it's not even in quotes. That is real. Not to make a huge deal out of it, but I swear the five second rule or give it five minutes, right? This, I swear half the reason why people don't use React is because of that. This guy's one of them. He's still writing in jQuery, it's fine. But it's pretty powerful, right? So if we don't just have access to our own tags, we can create whatever tags we want, right? So this stalks tag here, that's our application, right? And we've got a stalks tag and we've got this thing called show here. It's just an attribute. And this is Apple and Google, right? So we're passing in a list of stalks that we care about. So this is an extensible component. You just tell it which ticker symbols to listen to, and we've got an auto-stark flag. Should the ticker start going as soon as the page loads or should it not, right? And so the reason why I said don't freak out is because it's actually totally optional. You don't have to do it. I promise you will like it. But this is the same exact thing, right? So your custom component just translates into a function call. And all of those crazy looking attributes, all they are is a key value object. Passed in, like if you ignored this, this is not scary. There's nothing scary about that. And this works with nesting all the way down, right? So if you don't use a built in, I'm sorry, if you don't use a your own custom element, you've got this thing called react.dom.tagname. In this case, it's the UL. And those are just functions as well, right? So this is the same exact UI built just typing out a function to yourself. So you can do this if you want, but I promise after that five minute of the evaluation period, this is gonna look a lot better to you. All right, so we talked about passing data in. We saw those properties as they come in. They're called props in React. So those are immutable. Once they're passed into you, you're not allowed to change them from inside the component. It's got this, part of the React API has get default props. So this is your way of saying, here's the default state that I wanna run in if nobody passed anything into me. So no more dollar dot extend or underscore dot extend and hitting options that way. And this thing I think is pretty cool. It's totally optional, but you can, they have a built in validation for it. So you can just say auto start. This has to be Boolean. The show, which is that array of stock ticker symbols, that's gotta be an array and it's required. And it has built in support for things like, give me something renderable. That's a lot of different things. I forget the list, but it needs to be another component, a function, the number, object string. You can say it has to be an instance of a particular type of object.  So if things are starting to go awry, the React is gonna let you know about it. So that's state that's passed in, but you can also have a self-generated internal state that cannot leak outside. That's the component-based nature of the stuff. In get initial state, you consider this your declarative constructor. So you just say, here's my initial starting state when I am constructed. I'm gonna have an empty list of transactions. Again, so this is the real code pulled from that stock ticker example, just to clarify. We're gonna start with an empty list of transactions and then we care if we're running or not, if somebody toggled the start stop. And we're gonna default to what was passed in on that auto start flag. But then over time, things change. So start ticker, when you press that start button, we're gonna set the set state, this dot set state of running to true. This is the first time we're seeing any sort of mutation here. And when that happens, when I said continually re-render, this render function is gonna get called any time you call set state. And it's going to figure out in this UI what cares about if we're started or not. And in this case, there's only this dot state dot running. This is the, it's only gonna render that button again. It's not gonna re-render everything. And then that was a real time data feed of stocks. It was simulated, they're not real numbers, but you just give, you have this callback and this is just a JavaScript object. This is not, I named it that. That's not a reactism. And we just, it has data that comes in. We add it to the list. We pop off the oldest one if we're beyond our maximum. And then we just set state again. And then it will trigger render and the process continues. And you can see, you can nest these things as deeply as you want. So it knows that the only thing it cares about transactions is that magical transactions tag there. So what is that, right?  So the application itself is a React component and everything inside it. So that last one we saw was the application shell. This transaction is just a list, right? So when we render, we start with empty data. When we render, we're just gonna be a UL and we're gonna just, this is built in JavaScript. This isn't anything invented. We're gonna call map and we're just going to say for every single transaction in the list, let's just build this list item. And as I said, you can go as far as you want with this. If you have too much logic in your building your LI there, if it doesn't look comfortable to you, these are just JavaScript objects. What do you do? You create a different one. Take your abstraction further. Instead of building the LI there, if that got too, if it was too cluttered, you just introduce a new component, right? An individual transaction item. And all that is, it's just basically another render call and you say, I'll abstract all my details that care about rendering here. So if you start having things like, you wanna delete things from the list, refactor it out into its own component and they nest and just adding these tags is just as easy as adding a button tag. All right, so handling events. I feel like I'm beating this to death, but these are just regular JavaScript objects. So handling events, you just attach regular JavaScript functions and they take an event object just like a normal event handlers do. That is the same thing that you're used to using in the browser. And to wire these up in the UI, all we do is we've got this button tag here. We just pass in and on and click handler. This is the second freak out moment that people have. What is this, 1999? What are we doing here with this? Number one, I assure you that this is not a one-to-one translation. It does not inline your handlers. This is an abstraction, if you remember. It reactos the right thing behind the scenes. It adds one event handler to your application. It is at its top most layer. And it uses event delegation by default. So all, the proper way to do events is actually what gets rendered in your app. This is mainly so you can see everything that is happening in one place and visualize it. This will be a quick overview of life cycle, right? So your component needs to know about when things happen outside itself. So there are certain hooks that React has. Component did mount is one of them. This will get called in you when you are finally in the DOM. You know that you are initialized and you're in the DOM. So if you need to do things like integrate a jQuery widget, you do it here because you can rely on being in the DOM. That mutations graph that I showed you, that's a React component I made. But it just uses the high charts jQuery thing, right? So it's just a simple wrapper over that. And I implemented in component did mount. I just initialized the plugin. Simple as that. Component will unmount. You're about to be removed. Clean up after yourself. There's a whole bunch of these. I'll just talk about two more because they're kind of fun. Component will update. If during the render cycle, it React has determined that you need to re-render yourself. It will call component will update on you. It will pass in the next set of properties and state that you're gonna get. Think about creating your undo redo system for your application. Most of it is here. It's saying you're about to change. Here's the old state. Here's the new state. Just save off the old state. Pop it back on if you wanna undo redo. There are particular cases you might wanna override this rendering behavior, right? If you think you're smarter than React for a particular use case, if you're using immutable data for some reason, should component update? You answer yes or no, return true or false. You evaluate the old state, the new state. So that is where your, by default, it will be super fast and do the right thing. This is where you go if you need to do performance optimizations. Speaking of performance, this is a direct quote from yours truly. How is that not slow? I saw this presentation at a conference earlier this year. That just doesn't make sense to me. Constantly diffing, nothing about that sounds fast. Let's think about what, so what makes a user interface slow? As we talked about, DOM mutation makes the interface slow. Adding things, removing things. Every time you change a class name, the browser's gonna repaint and reflow everything underneath it, because it doesn't know what new CSS properties are gonna come in. That is expensive. So the whole point of React is to minimize that as much as possible. That is its entire reason for existence, is to apply that scalpel approach and only change the very minimal amount. So I'm gonna have to go through this a little faster since we got started slow, but it does this because it uses a virtual DOM. It doesn't touch the real DOM until the very last moment. So that unordered list with the list items, those are just JavaScript objects in memory, so manipulating those is super fast. And then at render, when the render cycle goes through, it says, all right, now it's time to compare the actual tree of DOM nodes to the tree of objects you have and reconcile the differences in the most efficient way possible. So that's how they get the performance benefits. Batched updates, I talked about that a little bit. It doesn't, it will batch two or three changes together at once to minimize the impact. The synthetic event system, I talked a little bit about event delegation. It does that by default. But who here has ever written a hover handler before? You move your mouse cursor across the screen. Have you ever put a console.log in that callback and looked at it? How many events does that generate? A lot. What gets passed into every single, one of those callbacks, an event object? So what React does by default is it uses object pooling. So instead of creating new ones on every single pixel that you move your mouse, it's gonna have a dedicated pool of those event objects and reuse them to kind of keep memory consumption low. Everybody loves benchmarks.  This is, I didn't even read the details on it because I'm not gonna get into it. This is saying, this is how much faster we are than Angular. But that's not really what matters, right? We don't write a loop that just goes 10,000 times and stuff like that. So I thought it would be more fun to just look at a visual demo, right? So I have to give thanks to a guy named Steve Lusher who actually created this demo. I asked him if I could use it because I think it just really kicks ass and he gave me a person. So thanks, Steve. All right, so what are we looking at here? Looks like chaos. This is actually a 1,000, it's 32 by 32 grid of pixels. Those are individual divs, right? We put that to the web audio API and generated a sine wave. So this is just a fire hose of data that is coming through this pixel rendering abstraction. So there is 1,024 little div pixels in this. Each has their own internal state of brightness. Am I a zero or am I a 0.9? Anywhere between zero and one. This is the sledgehammer approach. So this is re-rendering everything every time. So let's just poke around here and see what's going on. When I'm hovering in here, can't even see it now, but there's a, see everyone's smile, you see it. There's a little outline. Every time you hover over a pixel, it gives us a little visual indicator that you're hovering over it, see? But you notice it goes away, that's kind of funny. Down the bottom, it's real small, but there's a thing called mark. And what it's gonna do is it's gonna paint everything red. So every pixel gets painted red and then normal rendering resumes. That was pretty quick. All right, that's interesting. And up here, we've got this FPS. Doesn't matter the technical details behind it. We can call it fancy pants statistic, for all I care about. The important part is the higher that number, the better. That is throughput for our UI. So we're hovering right along about 19. But like I mentioned before, the reason why this is disappearing is because when we have this imperative way of touching the DOM constantly, it's tearing down DOM nodes and rebuilding them. So our state, like I said, the DOM is stateful. It does not keep that state. That is sort of outside of our framework. It's throwing away the DOM node and rebuilding it. So that is lost. And the same thing that's happening with this mark. Even the DOM nodes that haven't changed, that went from zero brightness to zero brightness, they're being repainted. So we're gonna see if React can do better. So for me, this passes the eye test. There's just more chaos, right? But if we look up at our fancy pants statistic up here, cruising along much faster. If I remember correctly, that was about 20. Something like that. So now, that's a bigger number. That's a good thing. But like I said, the eye test, it matters here, right? This is obviously rendering faster. But what is important is that we're also not losing our hoverability, right? Because it's not tearing down nodes it doesn't need to. It's saying, you know, that hasn't changed. I don't need to touch anything with that. We can also, this will be a little better. We can paint, and you see everything goes red, but it doesn't disappear immediately, right? Because those divs that went from no brightness to no brightness, it says, yeah, red's fine. I don't need to re-render myself, nothing changed. So it's sort of, it's a very interesting example, very visual way to show what is actually happening with the DOM in this React version. So we can get a little bit bigger. So we're working with 1,000 by 24, by 1,000 by 24. What if we double it? This is 2,048 divs. We see, this is the native version. The same thing applies here. Stuff is being torn down. Eight, nine frames per second. Jump over to React world. Not as fast as the other one, but we're talking about 2,048 divs in here. Constantly changing. Same idea applies, right? We're hovering, we're doing a lot better than we could be otherwise. Again, that scalpel, that precision approach. So I'm gonna ask a big favor of you guys. We're gonna do one more demo. But we don't have a sine wave anymore. So we're still gonna, we still got our same program. We've just changed the input. When I stay quiet, things go. So I think you know what's happening here, right? We no longer have a sine wave. I've hooked this thing, it's directly hooked up to the microphone in my laptop. So what I'm gonna do is I'm gonna see if we can make 2,048 unique individual noises to repaint every single pixel on this UI. So I'm gonna paint everything red at the count of three and you guys need a pound on the table, scream, clap, do whatever you want. But our goal is to make sure every red pixel is gone. So 2,048 unique at the count of three. One, two, three, go. One more! My boss is here. Thank you for not embarrassing me. All right, so we're running a little late on time, but this is honestly what I think is the most exciting part about React, right? It's that functional programming is great, but in the browser, it's like, how do you apply some of those principles? Where the DOM is stateful, everything is stateful. Well, when your framework becomes stateful, this opens up a whole new world to you. You can sort of apply these new patterns. So of course, you know, we're gonna talk about monads today, now we're not, definitely not. Do we have any functional programming experts in the room? We can just make stuff up. I am not a functional programming expert at all, but when you apply some of these little principles, and you see the benefit that you get out of it, it can be pretty liberating, right? So for today, we're just gonna keep it simple. We're gonna say, to be functional, we need to have composition of functions as the primary mechanism for the building programs. It's a fancy way of saying use functions. And some measure of immutability. So to get the predictable parts of functional programming, we need to have some measure of that, right? And that's all we're gonna deal with today. I can talk about this the fall day, but composition of functions is the primary mechanism, right? So when we go back to our example before, we showed that crazy JSX stuff and that it just gets converted to function calls, at the end of the day, your application is just one big set of nested functions. You just don't have to build it yourself. You just build DOM nodes. So I'm gonna give us a big check mark there. We didn't even have to do anything. We're already functional. Some measure of immutability, right? But why? But why does that matter? I like this is a quote from Functional JavaScript, the book by Michael Fogus. Practical functional programming, because we're not doing math here, we're building UIs. So practical, it's not about eliminating state change, but it's about reducing the occurrences of mutation to the smallest area possible. I like that quote. What does it mean? So we play a game, find the bug. We just create a transaction object with the amount of $100. Then we're gonna do some things in our application whether we're gonna calculate the percentage, we're gonna add it to the ticker and we're gonna do one more thing. It doesn't matter. There could be a hundred things in here. Then we get to the bottom. We're gonna print out what the transaction amount is. But you just got to work on a Monday and all of a sudden this is printing out undefined in your UI. Where's the bug? One of those three functions. Which one? Is that a good thing? So what if we just made one tiny change here, right? This isn't React code, this isn't anything. This is just JavaScript. Don't worry about what object sufferease is. I don't even know all the details of it, but this is sort of a new thing in JavaScript. You say make this object immutable. Nothing else can change it anymore. All of a sudden we start seeing a hundred here, right? But what if it wasn't? What if it was still undefined? Where's the bug? It can only be in one place. We froze the object. We now know the only place this bug can be is in this transaction creator there. So this is obviously a small example. Imagine if this is a hundred and imagine if any event trigger in the UI can also change it. Imagine how much hotter our debugging process gets. So what we're looking for, that's the big thing behind immutability. It is not just a fancy concept. We're looking for predictable behavior. And by default when you pass in these props into a React component, they're immutable, right? So if this is our application and we've got this object out here and we're passing it into this big tree of nested components, we can rest easy that what we get out is gonna be what we expect. All right, so we're all fancy functional programmers, but what if I want to the components updated? Then what do you do? Have you guys heard of callbacks? No, I joke. It's a very simple concept, right? So in our component, instead of just passing in the data model, you just say unchange, we're gonna pass in a handler, right? So now all of this mutation still happens in that one place, right? We're limiting the amount of change in our application to this one spot, but we're just enabling other components to update it by giving it permission by passing in those components, right? So this is what I talked about at the beginning about, React doesn't do too much data binding, but that's not a deficiency. That is a core design principle. So we talked about immutable data being passed down, right? And events going up, right? So this is that callback. That's events going back up to the source components so it can do the updating. This could also be a pub subsystem if you want, but the idea is if you remember that MVC thing with arrows going in all different directions, this is their answer. Say we've got this big reactive cycle where data goes down. The callbacks or events change data and then that data trickles down and then the re-render happens where React will calculate what needs to be updated. So this isn't an accident of course. This is a quote directly from one of the core creators of React. They had this as an exact design philosophy, right? Minimize the time to find root cause. And they did it by introducing these subtle functional concepts but you don't have to be a professional functional programmer to use them, right? We all... This is a contrived example, right? But if the property values that came into your component are incorrect, the bug came from outside of your component, right? If everything was passed into me correctly but things aren't still rendering right, you're the problem. That's the component you need to fix. So that's sort of true, false, whereas the problem is pretty liberating. This has nothing to do with functional programming but we all know what DevTools looks like. We get this little React guy in here now. That's not an HTML tag. That's our application. And by clicking on it, you can actually manipulate the DOM but look at this, you also get the state, the running state of your application and the property. So they went... That minimize time to find root cause is a real thing. It is like, that is a core design principle all the way down to the tools that they provide you. And Hukia works for a company that is building just less user interfaces they go on. Like who's saying like, now let's go back to static pages that turbo fingers keep refreshing the page. I wanna work for your company then. No, complexity in software is only ever-increasing. This is not gonna get easier, right? So we only have one, there's only one thing we can do. We can't stop that. The only thing we can do is to choose simpler tools that solve these big problems in ways that just, let us be more sane as developers. We don't wanna illustrate still 100 functions to find the bug. I wanna get to that thing as soon as possible so we can move on to more interesting problems.  Follows out, like server rendering, we're not doing it with the DOM anymore. So you just, it's actually your components called render component string. That works not just in node, that works in Rails, that works in Java. I have links if anyone wants to talk about that afterwards but I won't talk about testing because we're running low on time. Immutable data structures. So we talked about functional programming, it being like a core thing in React. You don't have to write. You don't have to know too much about it but it's a scale, it is not true or false. You are not functional or not functional. You can just adopt these principles slowly as you go and they've Facebook released an immutable data structures library for JavaScript which helps with that. And no green field app needed. You can start rendering one button on your UI in React. It doesn't need to take over your application, you don't need to rewrite everything. I don't wanna keep rewriting the same application over and over again. And I do not work for a company that builds a new to-do list application every month so I don't get to use all of these new frameworks as they come out, it's just not feasible. So in review, this is what I really wanted everyone to take away, right? Domunibulation is painful and error prone and we need to really lean on our tools for this kind of thing, right? We can't be making imperative Domunibulation code as we go, that is gonna lead us to this insane weird place that we get into all the time with our applications. Just give it five minutes, right? And the five minutes that you start up there doesn't count, you guys all have to start over. I promise it's like the water's warm. It's not as scary as it initially looks. And lastly, functional patterns make programs simpler. I think, I hope that my, it was very cursory overview of that part of it, but I think that is the most exciting part, right? You can start very slowly going down these, understanding what these functional guys are talking about, but we can use it every day. So that's it. On the shoulders of giants, like this is, I'm gonna update this list. There'll be a whole bunch of ways to get started using it, tutorials, that kind of thing, best references, although now I'm just gonna say thank you. I'm gonna talk to me at lunch. I'm not sure if you have time for questions. Do we have time for questions? Does anyone have any questions? So the big sell, one of their big sells of JSX is that it's good for designers to work on a team. Have you experienced that? Do you have designers using it? I cannot say that we do. I will say honestly for that, that's gonna be the eye test, right? So let's see here. It's really just gonna boil down to what is easier for you to understand, right? It's actually like we're in the regular browser world here. We're not in React. You guys know what this is, right? That's their selling point. It is like the visual part of like when you look at it, you understand what you're looking at. And if you wanna add a class or you wanna add some like styles to that, you can just do it right there. Any idea how this is gonna play with the next generation web components? Yeah, that's a great question. I don't exactly know what the story is there yet, right? Because ideally, the analogy is there for custom elements, right? The only problem is that you don't get the immutability parts of it, right? Because everything is based on object.observe, which is the same thing as doing the data binding approach. So I think that's yet to be resolved. You could very easily have them work together, but I would worry about losing that big benefit. So I don't know. The future will tell, I guess. What do you use to build and how does that integrate into a JavaScript validation tools? What do I build? Yeah, do you use grunt or any other? Oh, sure, yeah. So JSX, it's just a simple transform, right? So there's a grunt task already. Like you just use that MPM module, or if you use Gulp, there are so many modules. You can just use it on the command line. That is like the easiest part doing that translation of the build step. Yeah, that's super easy. That should not be a concern. So I think we're probably over time, but if anyone wants to talk more, I mean, I'll be here all day. My boss is gonna make sure of that, so. Come and find me at lunch. Thanks, Ben, for a nice talk.


We're up here specifically to help the local law enforcement with any checkpoints that they need help with. The generators offer the solar power for our commanders and our higher-up, our command team to be able to communicate, charge the radios, have communication between all of the checkpoints that are miles and miles apart, and for us to just get the job done. We know that there's been plenty of struggle and there's been plenty of people that need the support and we are doing the best that we can and we're trying to get as much as possible to help continue these fires. It's difficult to be able to see that everything that they've lost, just to put ourselves in those positions in their shoes, to be empathetic in their situation. And as first responders, we want to do the best that we can to help them get through these tough times. I'm up here in Taylorsville for the Dixie Fire, doing traffic control points and making sure that looters don't get in. Well, I've been on two activations now. This one is the one that I've really done more stuff. Well, I'm supposed to be moving up here so it's actually kind of nice to get a feel of how the community is and everything. So I feel like I'll be really welcomed up here, especially since they all mostly know that I'm here with the National Guard so they'll probably be really thankful that I'm serving the community as well. So day to day, we're just running TCP's, which is checkpoint just like here. I've never seen anything like this, like when we drive through Greensville and everything's like burnt down. It's very sad to see, but I do recognize something similar from Paradise Fires. I had an uncle that lived up there, so we went up there to donate blankets and food. So it's very similar to that, but you feel good helping out the locals, letting them know that, you know, their houses are safe or their belongings, if they didn't burn down, there's no looters that come by. And just helping out the sheriffs and they're always like thankful, like, thank you for helping us out. It's pretty, it feels good, you know, to hear that from them.