 That's me and that's how I work for, and we're also hiring, so Jamie asked me to come and do a little introduction for 20 minutes on Facebook React. We've been using it aggressively for eight, nine months, quite young still, and we also started a React Meetup because there wasn't one, so we've had two of those and the third one's next week. So I just thought that I'd just give you like a brief overview, like 20,000 feet, we'll dive in a bit. There's actually nothing to it, so it's a really easy thing to learn. You can learn it in three hours, I think. It's not like Angular, it takes you three years and you still haven't got it. Right, so why am I here? Of course Jamie asked me, but one of my colleagues once said to me that he thought that everybody should learn a new language every year, and even if it's not the language that you end up using or programming in, it gives you a new way of looking at what you do do and you learn things from that and you can bring things from that into what you do. And it doesn't have to be language, it can be frameworks and there's lots of UI frameworks and I'm interested to learn about EMBA and I'm sure that, because EMBA is like much more sort of full stack than React React, it's just sort of like a little bit of it and so there's lots of unanswered questions that EMBA can, so I'm interested in what EMBA can do for us as well and I've heard that there's rumours of how React might help or something like React might help EMBA. So, we build our applications from lots and lots of different things, right, these days. Loads of different things like plugging bits of Lego, like Martin's slide, whole architectures, whole applications, all built from hundreds of different open source components and modules and things. So, we can mix and match, right, we can just use a bit of this and a bit of that and React is quite good at that in a way because it's very sort of non-intrusive, I mean you could just do like a little tiny bit of a web page in React or you could do the whole application in it but it doesn't, you know, and so it's all about putting things together and using the best tools for the job and working out how you're going to build it. I think there's some synergies between EMBA and React that might actually be useful in the future, I don't know where that's going but it might, but let's see after the talk because we'll see. I don't actually know anything about EMBA, I mean I did knock out for a couple of years, I did Angular for six months and I did Component.js, which isn't really a component but it's a component but it's a thing. And so we've been doing React for the last seven months but I've never done EMBA so I'm here to learn as well which is good. But if you fancy coming to the React Meetup it's next Wednesday, end of plug, right. What is it? So Facebook quite clever in the same, you know, it's a library not a framework, right, so it's supposed to be very non-intrusive and not getting away but it's a bit weird, right, it's a bit out there. So some people call it the V in MVC but I don't think it's that at all because MVC, the sorts of applications that we're building at the moment with React, MVC doesn't really play much of a part to be honest which is a bit weird, it's out there, right. Everyone in the world is doing MVC, we're kind of doing something different. There's already too many UI frameworks and, you know, why do we need another one. But this is kind of a really interesting thing so Martin's talk earlier was all about components and stuff. It absolutely is the future web development, it's component based development, right. I think we're getting to realise that and React is all about components. So it's actually quite similar to web components but it's not anything like them in the sense that it's something that's, you build your applications from component based hierarchies, exactly the same as web components. But they're not baked into the browser, they sort of float across top. One of the problems that React addresses is that we think that state is hard to manage. Applications become really complicated when you've got lots of state in your application. And if you talk to the functional guys, they don't have any states like evil stuff, you know, everything is just what it is. You just get data and that's what it is and there's no sort of managing state across an application. And React people say that two way binding is a little bit too complicated and in big applications it can get a bit messy when you've got lots of bindings to manage. Only if you use jQuery. And then this last one, which we'll come back to actually, which has been thrown at me a few times, which is like don't mix logic and presentation. And they think that React has poor separation of concerns. But I disagree with that and we'll talk about why in a bit because there's actually quite good separation of concerns in React but it's just different. So it's like, whoa, you know, it's different. It's not like anything and they say give it five minutes. Everybody that I've seen who's given it five minutes has actually, this is different but I quite like it. It's really, really easy to learn. So I said easy then and that says simple and obviously simple is not easy. You know, anything can be easy after you've learnt it. But it is generally genuinely simple and it actually makes building your applications quite simple as well because the way you think about building your application is very much different. We'll come on to that. There, complex interactions become easy to reason about. So when we look at how it works, we'll see that you get a hierarchy of components and there's no data binding anywhere near it. And you effectively are recreating your whole application anytime the data changes, which sounds like it would be performance nightmare and absolutely horrendous in the browser because we all know that the DOM is really slow. But because all you have to think about when you're building your application is if the data looks like this, my UI looks like that. That's it. So some really, really complex problems and really, really difficult things to work out. Actually just completely disappear and it's just this data says this happens in the UI and that's it. It's actually really fast. So you would think that re-rendering your whole application every time any data changes would be horrendously slow but it's actually incredibly fast. I want to talk about how and why that's fast and what they've done to make it fast. So this is out there. This post, I'll put the slides up somewhere, but this post is actually quite cool. Why you might not need MVC with React.js. So it turns everything on its head in a way in a sense that we're building quite big applications right now without any MVC anywhere near it, which is quite interesting. So to Martin's presentation, which was excellent, I thought, what about web components? Why is React different to web components? It is a component-based thing, right? Peter Hunt, who works at Facebook, he has been involved on the React thing for quite a while. They open sourced it nine or ten minutes ago. So it's quite young, but he's been working on the team and this is what he said. There's a lot of stuff you get for free when you build like the browser doesn't exist and this is one thing that distinguishes React from web components and Polymer and that kind of thing. They're getting closer and closer and closer in with the browser and we're getting farther and farther away from the browser. I think our technique is more sustainable among them. They're quite controversial, but web components are great, right? But you have to have the support or the polyfills or you're going to struggle on really old browsers. React almost treats the browser as a rendering engine and nothing else. When you do that, you can abstract away all the browser differences. So you program with an HTML5 compliant CSS3, actually CSS doesn't really come into it, HTML5 event system, regardless of what browser you're using, even if it's IE6, React sort of kind of puts this layer over the top which gives you this consistency so you don't worry so much about differences in the browser and they can do that because it's moved away from the browser. We'll look at how that happens. It's all down to this thing, the virtual DOM. The DOM is really expensive to update. It's expensive to update because the browser has to relay out stuff, it has to work out like, can you imagine how much computation goes into CSS? I don't know, but I could just, redrawing the page, it doesn't really know what it's got to do when you change stuff and it's expensive to update. We know it is. What they've done is they built this lightweight DOM representation over the top of the real DOM. It's actually not over the top, it's completely separate. It looks like the real DOM. There are H1 components and there's Diff components. There's a full HTML5 implementation of the DOM, but in real lightweight JavaScript objects. This is the key to how it works. When you build a component, the simplest component just has one function in it which is a render function. That render function takes some data and produces some virtual DOM. It's pure in the sense that it's idempote. You can run it as many times as you want. If you throw the same data in, you'll get the same virtual DOM out. It is literally just a way of translating your model into your view. It's literally, if the data looks like this, this is what you are, what you are want. It's pure because it doesn't have any side effects and you can run it as many times as you like. You'll always get the same output if you put the same input in. If you put different data in, you get a different virtual DOM out. That data might have just changed very slightly. When I'm talking about data, it could be a whole object of a whole, it's like a model of some sort, it could be anything. If it's changed, you get a different virtual DOM output. This virtual DOM is a representation of what your UI looks like. After it's created this virtual DOM, it runs a diffing algorithm and it compares the previous virtual DOM, what your application looked like before with what it looks like now. It computates the minimum set of real DOM mutations or modifications that it needs to make. If in the model you've added an item to a list and that's an extra Li element in a UL, then it would work out that it's got to just add that or where it's got to add it. It doesn't re-render any of the rest of the DOM or we actually regenerate anything else at all. All it does is make the changes that are correct for the way the data is changed. A really interesting side effect from this, which we'll talk about in a second, is that if you do a diff between the new version and the old version, then you get undo. It's like the reverse set of changes. If you just literally swap old and new with new and old, you can go backwards in time instead of forwards in time with your UI. You get undo for free, which we'll look at because it's actually quite interesting. It's a minor point, but it is quite fun. How does the diffing work? This before and after looks exactly the same. What it does is it basically goes down each level and says there's one item there and it's this and it's got this data or it looks like this and there's one item. These are virtual DOMs, right? These are not real DOMs. It just compares them bit by bit, but if the text in this span changed, then it would just generate the DOM mutation that needed to do that. It works with these two things called state and props. Props are the things that are passed down into your component and they represent the data that your component is rendering. If you think of just like a diff tag for instance or a span or something like that, the props would be maybe its ID, its class name, any HTML attributes. Props and attributes, same word, they just call them props properties of your component. React has a component for every single HTML5, HTML element. You can interchange the word props and attributes, same thing. They're passed in by the parent component and class name is a built-in one and that sets the CSS class and is expanded might be something that you've invented to specify whether it's expanded or not. But state is internal to the component, never leaks outside the component and should be kept to an absolute minimum. It can, if necessary, be managed by a common ancestor. Imagine this is what we use state for. We almost never use state. We always pass stuff in through the props and we'll talk about that in a second. But the state is absolutely minimal. If you think of a radio button or something like that, the state could just be managing which one's selected or something. It's not really related to your model or the wider application thing. It's just quite self-contained. But if more and more component needs to work with the same state, then it would be stored in a common ancestor. And then these are the methods that you get in your component to handle state. So there's a get initial state which just returns an object that specifies what the state for that component is. There's a set state and set state is quite important because that allows you to change the state of the component. Force update will cause your component to re-render so almost never use it. It's almost unnecessary. A component render allows you to specify whether, if you know more than reactors about whether that component should render, you can return false from that and it won't actually do it. So it's a way of getting even more improvements in efficiency. So set state, if that's your component hierarchy, your sort of virtual DOM on the left-hand side, in every place that you call set state, so if you call set state here, here and here, it marks those as dirty. It's only those elements or components, children that will get rendered. So on the next render pass, only those marks as dirty or only ones that you've literally called set state on change. So this is what a react component might look like. This is the hello world example. So there's a render component method which you can render any component with and you can render that component into this DOM element. So that says render this component called h1 into this DOM element in my page. So this might be the only DOM element there is in my page. And it's an h1 that has no props. This is where the props go in the first argument. So it has no props. So we don't want to pass it a CSS class or anything like that. We don't want to give it an idea. We just want to give it a child. The second and third arguments are the children of that. And it will actually create a span for us or whatever it needs to do to. But we could have specified a span if we wanted to. But the problem with building components in JavaScript is that it can get really messy. Get out of hand really quickly. You've got lots of indenting to do and it can look a little bit messy. So they invented this thing called JSX which is like a JavaScript with some kind of XML-like syntax embedded into it. Which allows you to have a more familiar HTML-like approach to writing a component. So that is exactly the same. So JSX itself doesn't do anything. It's just a compile to JavaScript language. Just like loads of compile to JavaScript languages. And that H1 literally just becomes react.dom.h1. And it just compiles to that. So you can do either. And it depends. They think it's great. I'm not so sure. I think it looks a bit weird. And Red Badger were quite big fans of LiveScript which is sort of bare bones minimal from a look and feel. So stripped back JavaScript. Bit like CoffeeScript. A bit like what CoffeeScript should be. And that's exactly the same. So that's exactly the same code in three different ways. JavaScript, JSX and LiveScript. So you don't need comers where you don't need comers. And it's quite sort of stripped back. But what it does do is it allows you to write components that are actually really readable. So this component is a tab, two tabs on a page. This tab is active if the shopping method is delivery. And this tab is active if the shopping method is collection. And it uses React to Creator class. The display name will come onto in a bit. But that actually allows you some really good debugging tools in the browser so you can see where you are in your application. So this is effectively in web components like what goes into the tag itself. What could be called a tag name, I guess. We've got some mixins which are just going to give us this translation helper and there might be a link helper or something. And it's the simplest form of component. It only has a render method. And all it does is create a URL with class name tags and two allies in it. The first one has a class name of... So it will have a class name of left always and it will have a class name of active if the shopping method is delivery. Then it creates an anchor underneath that with an href in it, which formats the... So we're parsing a store which has got the data in it in the model and stuff like that and it's got some helper methods on it as well. So it knows how to format a URL for delivery and that becomes the href and then we've got a translation there. So these are the props and these are the children. This is the child. We'll just go in as the content of the anchor and then the same thing happens on this side. And that's it. There's no data binding or anything like that. When the data changes, it re-renders the whole thing, rebuilds the whole thing. This is another example also in life script. So also a very simple component. It renders a header element with that class name and then it pulls in another component called cookie policy which is basically just a typical cookie thing, policy, acceptance thing. But it only does that if the configuration says that it needs a cookie policy and the next creates a div. So this is quite interesting. If the children of the div here will either be... If there's a shared council there will be an anchor in there, otherwise this anchor will always be there. That's the second child. So you can see how you can create a different UI depending on what your data looks like. Life cycle of a component is a well-mounted div mount. It will receive new props. Should it update, we talked about. There's a hook before it updates and a hooker after it updates and a hook before it unmounts. Almost never need them really. So data flows from parent to child just like one-way data binding effectively. That could be considered as your one-way data binding because you just pour data in the top and it's down through your component hierarchy. Then if you want to do interactions, one of the ways of doing it is to pass callbacks down from parent to child so that the child can call that callback when something changes and they can modify the parent state. That's a bit like two-way data binding. We almost never do that though because there are better ways of doing it. For instance, there is a synthetic event system which is like a full implementation of HTML5 events. You don't have to worry about old IE event stuff. That bubbles up and it's just exactly a delegated event system that's just all right to use, quite cool. Then there's this thing called Flux which is like an architectural pattern which Facebook have put on top of React which is really a simple one-way data flow around your application. Maybe something on the server changes or some action instigates is dispatched to one or more stores. Those stores do what they want with the data update and model and stuff and then they just say, I've changed and the view will go, OK, I'll redraw and redraws and maybe the user interacts with something in the view and you can then dispatch another action to the stores and they will update their data and they will go, I've changed and the view will go, OK, I'll redraw and it just goes around and around so it's actually quite similar to game programming in a way we'll come on to that but this is typically what Flux actually looks like that's an oversimplified version so that may be some web API or whatever and they create actions when the data changes or whatever dispatches through the stores register with the dispatcher and register some callbacks or when a message is dispatched to the store the data changes it will just basically fire event that allows the view to re-render so it's the same thing and a little bit more complicated so this guy Pete Hunt, we talked about good talk at JSConf.eu and at 20 minutes and 8 seconds into that talk he talks about this how he reacts a little bit like doing three engine and the doom engine you've got your game state and you're sort of like your world and then some game logic and then there's an intermediate representation of what the scene should look like and then there's a rendering engine which spits out stuff to the graphics card so in a game right you've got every pixel on the screen you have to calculate what the colour of every pixel is every single frame and the colour is influenced by all sorts of different things happening the way the light falls on the scene how many lights there are how it reflects off different types of surfaces lots and lots of calculations but it's all done over every single frame immediate mode programming so it doesn't do anything unless you tell it to do it and React is a little bit like that in a way because if you overlay what the React parts look like on there on the F1 side you've got application state and events or whatever components which generate a virtual DOM which is like a description of what that scene should look like or what that page should look like and then it compares that with the previous one and then just fires them off to the browser and just literally treats the browser like a rendering engine so it doesn't actually it doesn't actually have to be in a browser that's quite interesting because this could be a string of HTML that comes out of here so you can do server-side rendering it could be SVG or it could be a canvas or anything it doesn't have to be HTML it doesn't have to be a DOM so it's actually just a sort of almost like a forward renderer in a game engine which is quite nice so isomorphic applications you saw a render component earlier you can render a component and slap it into somewhere in the DOM render component to string literally just because it's a virtual DOM right so you create one virtual DOM on the server which represents the state of your data and then you just say render component to string and you get a string of HTML and you send that down to the browser and the first load experience in your single page application or whatever it is you're writing and then you might want to have some client-side routes and carry on client-side for a bit and then you will press refresh and the server will the same components are running on the server that you've written so you don't have to write your application twice the same components are running on the server render component to string generate a new string of HTML down to the browser and that's the state of the application for that page so it actually doesn't matter whether the server renders the page or whether the client renders the page which is brilliant for SEO for fast start-up you know you get non-javascript for free so if you literally turn an interactive application well an isomorphic if you turn javascript off you can carry on the same user experience obviously you've got a round-trip each time but same thing yeah so this in the top of the string there's a checksum when that HTML gets to the client you then call the client-side version of render component which is just render component and then inject the same stuff into the DOM again which it doesn't actually do because what it does is it creates another virtual DOM and does a checksum on that and if the two checksums are exactly the same and it doesn't do anything at all it just attaches the event handlers and carries on but if the checksums are different it will actually make the modifications to make it right but it will give you a big warning in the browser console that says that you probably didn't intend this because the server rendered one thing and now we're rendering something different am I running out of time okay cool but the great thing is that you can refresh any root like I was just talking about so any client-side roots press refresh and the server will render it for you so you've got a non-javascript for free and fast startup for single-page applications so if you deep link into any single-page application that's written this way it will start, you get that page server renders that page for you and you don't need phantom and jess or whatever on the server to instantiate your SPA for you so that Google can index the page so for anybody that does node this is like a little express view engine that I put together it's just nothing to it really but it basically requires the view which is actually a react component and it calls render component to string so it instantiates a new instance of that component passes it the props that we were talking about which are on the local so think of this as like say it was a jade view or whatever these locals which would normally be passed into the template actually passed into the component instead and they become the data for the component you just render that basically into this locals.content and you have just one template which just injects that HTML into that the placeholder in the template that's it server side and an example of how you might use this in an express route so this, I don't know where this is from part of the application that we're building at the moment so getting products with this ID passing some context in so that we know authenticate with our API and then that's going to return a promise of a body and a status which we're not using status but the body become the props for this react component so it's very similar to how you would use templates in express or whatever so because we've got this this view engine plugged in res.render we'll just pass that into there and then create the HTML pass it down to the client right so I can't do this without talking about immutable data for just one second because I think this is where the future of React is probably going to need to go or going to go to so Dave Nolan wrote on which is a wrapper around React that is written in ClosureScript and because ClosureScript is immutable by default there's some amazing things happen because from a performance perspective I've got one more side about that which is quite interesting but he stripped out all the immutable data structures from ClosureScript and created Mori which is like a miniclosure script but for a JavaScript world but it's still quite heavy and then Facebook came out with immutable.js a month or two ago which does a similar sort of thing but it's a bit lighter sort of 10 code gzips or whatever but it turns out that if you can make certain guarantees to your React components that the data you're going to send into them is immutable then it can make all sorts of incredible optimisations about how it renders that data so um yeah so I'm wrapped by David Nolan immutable data structures they have structural sharing and stuff so it's actually really efficient so basically what any immutable data structure what a persistent data structure or immutable data structure is is that every time the data changes instead of actually changing it in place you would get a new copy of the object that looks like a complete brand new copy of the whole model underneath the cover that uses structural sharing so it's actually not creating a brand new copy it's not actually doing any copying at all it's just all pointers to to arrays and stuff so it's really efficient and really fast but it looks to you like it's a brand new copy so it's a different instance to the instance you gave it and you changed it in such and such a way and you got a brand new one out and if you pass immutable data structures into the top of a React component then or React hierarchy then it can look at your data model and it can say well actually this instance is exactly the same there's a reference equals it's exactly the same as that one so I don't have to do anything I know it hasn't changed so I don't have to re-render anything and I don't have to re-draw and I don't have to re-create anything and so from should component update you can return false from that which says don't do anything you can leave this part of the tree untouched because if I've got the same instance it can't have changed because it's immutable if I've got a different instance then it probably has changed or something underneath me has changed so I need to go at least one more level down and see which of those are equal and which ones aren't and it turns out to be a really really fast way so fast you can do it in request animation frame you can re-render your whole application in the 16 milliseconds you get so so who's using React not many people Facebook obviously GitHub I started to use it quite a lot so the atom editor is written in React now or at least the editor part of it is CircleCI that Jeremy mentioned to me today which is written in ARM and Goya which is also written in ARM is actually quite amazing I might just jump in and have a look at that because this is quite stunning this is a pixel editor which is pretty boring but and I've borrowed all this stuff from various talks but in the left hand if you can see down here it's a little preview pane and stuff so I put some hair on it and on the right hand side I'm getting so I can go back to is it not working what have we done oh that was the history so under typical demo hey I'm going to refresh that start again yes it's creating a history down the right hand side not a very good draw am I I don't know what's happened a really good demo that didn't work no mind really embarrassing that watch the video that that Dave Nolan on YouTube just it's actually quite amazing and it worked for me last time maybe there's a new version of Chrome or something anyway so that's React any questions oh maybe it might be worth maybe there is a demo of Facebook obviously React and so is Instagram and stuff but there's a really good React thing here that you can use to so this these are React components and then you can see this particular instance all the data that was passed into it and you know all the all the particular data that's on this instance there's also get DOM node as well so you can actually jump out and get the real DOM node if you want to do fancy animations or whatever you want so yeah cool any questions can we see some of the things that you've built yeah you can actually you can you can so I can't we're building a big application for a big grocery which I can't talk about until it goes live in two weeks' food time and then everybody can see it but so yeah probably not this React meter but the one after that we're going to demo all that but we did build help.sky.com with React so the team that we've got on that team so I don't know anything about this application and I'll be the worst person to demo it but but it is responsive so but these are all React components so if I so it's actually quite interesting in the sense that there are actually different components but because as you the state as it changes from one to another the state is preserved even though the whole component has been swapped out for something else because it's just reflecting the same model but if I I go into that wasn't what I wanted to do that was what I wanted to do if you go into the React tab so can anyone see this this is too small is that better so there's an index page with a tags control in it so you know very similar to web components in the sense that you get this special I've probably gone a bit big then which you can see the different parts of the application so this has got a topic group small but if I went wider probably it would become a topic group large or something it would probably just switch out we should go smaller I know maybe I didn't write this but it's what our team is guiding as you can see so there's a mixture of what looks like HTML5 and what looks like custom components and then if you selected one of these then this has got a bit of state in it is selected as true hasn't got many props I would have written that differently I had more props in this state because that's one that's one thing we've got I want to shave it I think I can't do that next time so is it true that the the virtual dime is better than the show done I don't know I don't know but it's an interesting question it's a question that's going to be asked a lot I think over the next year or so because as web components come to maturity which they will do I mean that they're always going to be because they're quite integrated because they're quite integrated into the browser they've got to wait for the browser to support them and all the old browsers to die off from them this is any browser going back and you just laser over the top you don't have to worry about so theoretically you can use it more now I think probably I think the key thing is that components are brilliant for reuse and building applications so that's the way to do it any other questions? Do you just use react or do you and obviously like close descript and almond stuff like you don't really have like M or C at all the whole structure and I guess how would you see it working with how would you actually make it work in these like because people say it could be the B and the envelope I see how you use it but now I'm not quite sure how you use it with with the envelope how would you think it would go about doing that? So the flux thing Facebook say it's not there's no software associated with flux just a pattern it's not strictly true because there are examples and you can still go from them but it's not like it's just a way of that kind of talks a little bit more about the rest of your application and how data flows through it but it doesn't doesn't really answer anything about how you structure your data or how your models or how you get data from a server or you know or it doesn't say anything about class and groups or anything so we build our applications just a little bit so everything from all over the place can I mention that sort of? Yeah exactly so I don't know I mean I can probably I can't show the application running back I can probably go into so those that's just the guilt part those are the dependencies those are the dependencies so there's all sorts of different things that we use from all over the place so I'm just going to throw them all in and React is just one of them longpoint 11.1 so it's just one of them on this and you do it mostly server side rendered so rather than client side stuff so kind of express and node and things so both so every sort of component runs the same on the client as it does on the server so the server renders it to a string send that string to the client we also send with with that all the data that it needs client side to render again and that's the key thing because when the component renders on the client it has to have access to exactly the same environment effectively when it rendered on the server because otherwise it won't produce the same output so if we had inline script and we can't so the content security process isn't out but we basically just put all the data into data attributes on the document and and then on the client side it just pulls it out and we render it using the same data and produces the same checksum and if it does it can carry on one more quick question on the other side how does the client communicate to the server? what do we use? we use super agent mostly or client side we use super agent server side sometimes they're super agent don't they? sometimes request but yeah there's no jQuery in that and it's all browser-ified up okay cool, another weekend