 Hi there. So a bit about me. My name is Rob Knight. I'm a developer at Hypothesis. We're a project that makes open source tools for annotating the web. And my background, actually, is my experience is mostly prior to where I work now, which is it's an Angular app. My experience is mostly with React. But more generally, I'm kind of interested in the cross-pollination of ideas between different communities and seeing how ideas from, let's say, one particular framework or tool can be used with others. So building user interfaces is all about tweaking things, about being able to make changes and see the effects quickly. I used to work as a native desktop app developer. And there, people were quite used to spending two minutes recompiling something after they made a change. So coming to the web world, where people complain if a build takes more than a second, is quite a change. With static content and simple web apps, this is easy. You make a change, you press a key, reload the page. In Ember, we go, Ember out of the box goes one step better. If you build, if you create an Ember project with Ember CLI and you're running it with Ember serve, then when you edit styles, Ember CLI will hotline, reload them into the page automatically. And if you edit some JavaScript, Ember CLI will automatically reload the page so you don't have to press F5. There is a limitation to this last bit, though. It loses the state of the application. So if you're doing things properly and you've got the most of this, and if you've got an application where the state can essentially be represented by the URL, and you're taking advantage of that, that's not a problem, the page reloads at the current URL, and it gets back to most of where it was. But supposing you have a more complicated application where you have a whole bunch of controls and you can't really easily fit that state in the URL, then you can end up spending a bunch of time after you reload getting the application back into the state it was in. And this can cost you a fair amount of time when you're, let's say, making some tweaks to something or fixing a bug. So initially, trying to deal with this seems quite problematic. I mean, JavaScript is a complete programming language. So how can you make it possible to edit code and preserve all the state? So hot reloading is a feature which was popularized in the React community. It, of course, existed in various programming environments a long time ago. But more recently, it's kind of come to, it's been popularized by React. And the difference between hot reloading and live reloading that MBCLI gives you is that hot reloading is about being able to make a change to the JavaScript code and have the application show that change immediately, but not lose the rest of the state. And so the first iteration of this in React was done with, shall we say, a hack. And it turned out that implementing it in a way that was robust required some more deep architectural changes. And that, I think, is what makes it especially interesting. So quick, hopefully, a demo of what we mean. So this is a fairly simple React app. And it shows a bunch of charts from different GitHub repositories. So I can put in the name of a GitHub repository. It will fetch some data, and it shows it there. So I've got a bunch of different charts on screen. So at this point, it gets a little fiddly to encode that data in the URL. So if I make a code change and I just reloaded the page, it would lose the whole, it would lose all the state so that it would lose the state of whatever's on the screen. So hot reloading is about setting things up in such a way that I, for example, so this is a chart, and it's created using JavaScript charting library. And it's all working. Yeah. OK. So I can make changes to the code, and the application will update automatically and preserve most of the state. Depending on how you set things up, there is some state that would be lost. So for example, if I had an input field focused, the exact text selection in that would be lost. But it preserves the most important state of the application. The other thing that's also useful about this is, so not only can you preserve the state of the application as it is, but sometimes you might have loading screens, error screens, unusual states. And the other thing that we can do is try out what. Er, da, da, da. So the other thing we can do is, if we have some state that only shows up briefly, ordinarily it would be quite difficult to sort of make a tweak to that. We'd have to go and edit the code especially to hack it into a state where it never finished loading, for example. So here we can, let's say, whine the application, easily whine the application back to some temporary state like a loading screen. And then we can go and edit the code, and let's say we wanted to tweak what that loading screen looked like. Done. So if I wanted it to display some text, for example, whilst it's busy loading, there we go. That's what hot reloading is. And hopefully you can see why it's a useful thing to have. But I now want to take a little bit of an into a look into the basics of how it works and the different kinds of pieces that we need to tie together regardless of the framework you're using in order to make that happen. We'll start off just looking at the basics of what do you need to do to get code when I make a change to just one JavaScript file out of my whole application? What do you need to do to get that code from the editor somehow into the browser such that your application can make use of it? And then once you've got the code available to the application, how does the application then take, let's say we have a bunch of DOM elements on screen and I write a new version of the chart component, how do we then find the relevant chart component and replace it with one that represents the updated state or the new version of the component. And as one we're replacing it, how do we then preserve the state of the application? So for example, here, how do we preserve the data for the chart, the current, whether it's loading, whether it's errored out fetching data, stuff like that. And then lastly, I'm gonna talk a little bit about how much of this can we use in Ember as it stands at the moment. So I'm gonna start off by taking a look at how it works with Webpack React and Redux and then towards the end I'll move on a little bit about how we might be able to apply this to Ember. So the first ingredients in hot reloading is delivering a code update from a file on disk. So I go and edit a source file, I save a change and then we need to get that code into the browser and we need to do it in such a way that the code on the page is able to given a chance to apply that change. So if you're using Ember CLI and you make a change to some JavaScript, it will reload the entire page and it will lose all the state there. Whereas here we want to somehow give the existing code on the page away to say, okay, there's a new version of a component available. Can we swap it in? The second thing we need to look at is, okay, if there are any outputs of the old code on the page, so for example, if we have a visual component or we change the code for a component, there'll be a bunch of DOM elements on the page that were created by that component. So we need to take those out and replace those with the new version. If we had code that played a sound effect and we changed it so that it was maybe playing a different pitch, then we would need to update the existing audio elements on the page. And lastly, again, when we update the could replace the components, we want to preserve the state of the application as far as possible. So in Ember, if you're writing application, you might have a bunch of state in, let's say, an Ember data store, but you might also have a bunch of state that's stored as properties on a component. And if you naively replace it, then that state gets lost. And this is where it becomes interesting because in order to solve that problem in a proper principled way, it requires changing the way that the application is architected to some extent. So the first feature, getting code up, getting code from the editor into the browser incrementally is a feature called Hot Module Replacement. And it's primary, and Webpack has the most solid implementation, but there are also implementations for Browserify and JSPM. And as far as I know, I'm not aware of an implementation from Broccoli at the moment. But I don't see any reason why it couldn't be added in the future. So there's two parts to Hot Module Replacement. There's, first of all, the part that runs in Node, that's the server, that needs to detect when you've edited a JavaScript file and generate not an incomplete bundle as would normally be the case, but a little mini bundle containing only the part of the code that's changed. And on the other side, we need some code running in the page that is able to talk to that server and to respond to requests for updates. So an application is divided into a set of modules, which depend on each other, and one of these modules will be the entry points, typically the app.js file or index.js file. And this structure forms a dependency graph. So on the left, we have our files on disk and then our module bundling system. So an embassy ally that will be Broccoli. In React, one might typically use Webpack. Browserify is popular as well. Turns that into normally one big JavaScript file. So when you edit a file on disk and you have hot module replacement enabled, Webpack will generate an incremental update containing only the code for the module which changed, and it then sends a WebSocket message to the client to notify it about the availability of that new version. The little client runtime, which lives inside the page itself, then fetches the updated code. So that's all generic. However, the little client runtime in the page has no idea how to apply that update. It doesn't know whether you're using what framework you're using, what there is on the page that would need to be replaced, how to go about updating the code. So you need to provide some logic that can take, that once it receives a note, it can register itself for a notification of a new version of a module being updated and then actually somehow apply that update to the page. So although the client doesn't know anything about what's on your page, it has no idea if it's a graphical application or something completely different, but it does know about the dependency graph. And the basic idea is that modules register which dependencies they can process updates for using an API called module.hot. So for example, in a very simple application, which let's say this is our main index file, and it's an application which renders a loads a button component and renders it. And what the app.js file can do is it can register to say, if this dependency changes, then I can apply those changes into the page. So, and you provide a callback that's invoked when a new version of that component is available. So in this case, if a new version of the button component is available, sorry, I've got the variable name is wrong there, then we're given an opportunity to load a new version of that component, and somehow we then need to actually go and find all the instances of buttons that are on the page and replace them. And that might involve entirely, so the dumbest way to do this would be to tear down the entire user interface and recreate it from scratch. And actually that approach, if you don't have a lot of state in the application which you need to keep, that fairly dumb approach actually can work quite well. So remember, a very simple button component might look like this. With a label and a click handler. And in React, the same thing looks like this. But an important thing to note about React, component in React is whereas, so this is a template, lives in a handlebars file, the process of actually getting that onto the screen is somewhat sort of hidden from me behind the scenes. In React, component is just a function, just returning an object, describing what the DOM structure of the component should look like. So therefore it's a little bit easier to see from that how we go to loading a new version of a component in. Since it's a function, we'll have other pieces of the code calling that function. And what we need to do in order to load a new version of that code is find the places that are calling this function, the old version of it, and getting the call a new version instead. So when the new version is called, it will then return a different description of what a button should look like. And React will then take care of updating whatever's on screen to call that new version. So this, without using any fancy, without using any fancy transforms, or sorry, without using any additional tooling, this is the basic sort of hello world of hot reloading in React. So let's suppose first of all, we get hold of our button component and we call react.render, which takes a component as input and it will then render it, which is the process of actually going and creating that component into some container on the screen. So in this case, we imagine we have a div with ID of root and then we want to render that component into it. So when the app starts up, it will react, will render that component and we register the fact that if a new version of the button component is available, then we can handle that and apply it live. So what will happen then if I go and edit my button.js file is that this callback will be invoked and we're given an opportunity to load a new version of the component, at which point we say we call react.render again and this will then take everything inside the root component and replace it with the new version. So that gives us the ability to reload a simple component, but there is a downside. If I'd actually stored any state inside this button at this point, then that will be lost. So question is, okay, how do we preserve the state of components and what happens if you want to make changes to services or models or the logic in your app as well as views? How do you keep that all working? So the standard solution to this problem in the React ecosystem is the Redux library and Redux is as much a design pattern as a library. It's a very small thing. If you look at the tutorials, the tutorials are, I think they're sort of, maybe about 30 minutes long for the basic tutorials and they essentially explain how to implement the library as well as how to use it. And it's a small framework independent library for managing how app state is stored in your application and modified. And it's based on three key ideas which together give you an architecture that enables you to get hot reloading in your application. And instead, it's much a design pattern if you like as a library. It comes, it's history. It was inspired by a language called Elm which is a functional programming language that looks a little bit like Haskell if you've ever used that at all and it compiles down to JavaScript. But the interesting thing in Elm is that whereas in MBU component might have a bunch of properties in React, you might have a bunch of state in your component. In Elm, components are always stateless. They are just a collection of three functions. So how do you get a UI component from three functions? So the three functions are first of all an init function and that gives you an object which describes the state of your component. So for example, if I were to look at my charts, the state of the component might be what is the data that's currently loaded in, what repository is it currently showing, what color is the line? So the init function, when you call that, doesn't take any arguments, will give you the initial state of the component. And then the output from that is fed into a function called view. And the view function takes some state and transforms it and gives you an output which is an object describing, okay, if I have a component in a certain state, what does that look like when it's rendered into the page? So effectively a tree structure with some divs, spans, et cetera. And then finally, in addition to describing what the output should look like on the page, it also describes which event handlers should be attached. So maybe for example, if you click on a button, then what should happen? Then what action should be triggered when you click on that button? And when you do click on a button and you trigger an action, the Elm framework will then take care of, the third function, which is called update, and it will pass as input, the current state of the component and the action that has just happened. And then your update function is responsible for giving you the new state, at which point the new state is fed back into the view function and you then get a new updated description of what that component should look like on screen. And the Elm framework will then take care of actually modifying the DOM to make it look like that. So the important thing to note here is we've got state, but it's architected the Elm architects things in such a way that the state is all stored outside the component, which means that we can replace all of that block in the middle without losing anything. So if we have an Elm component and we want to replace component version one with a new version that we've just hot reloaded into the application, what we need to do is just find the arrows that point into that component. In other words, the places where we're calling the three previous functions and instead point those arrows to the new version of the component. And then once we've done that, the component will then immediately update on screen, but because our state is stored outside the component itself, we haven't lost that. So in the case of the charts, for example, if all the chart state is stored outside there, then when we load a new version of the chart in, maybe has a different line color, it displays the loading state differently, that information is still available and the chart carries on rendering. So that's Elm. Reaction Redux is slightly different from Elm. It's inspired by Elm, but it's slightly different because whereas in Elm, you have a component is three functions, usually typically all in one source file with a reaction Redux, they're two separate frameworks. So you would write just two functions. So one of your functions is the component itself and the other function serves the role of the init and update functions. So the data flow here is that first of all, you write a function called a reducer which effectively models the state of your component. And initially, Redux is initially when you Redux is a library which, eh, start again. So Redux's entry point is an API, is a function which will create us what's called a store. And the store takes as input a set of a reducer. And a reducer is a function which, when called with no state, will give you the initial state of a component. So for example, a blank chart. That state can then be fed into a react component and the output of that will then be whatever a blank chart looks like, for example. As well as feeding the state into a react component, we also feed a property of the Redux data store which is a function called dispatch. And whenever, and that serves the role of event handlers. So if I click on a button, then that function gets called and when that function gets called, it then feeds an action along this red arrow here together with the current state of the component. So for example, on the right hand side here, I'm using the debug tools that come with Redux. And what you can see here is a list of the actions that have happened. So for example, when I started the application and I typed in Facebook slash react, that triggered an action called set repository. And that then changed the state of the application. So what I can do here is I can cross out and say, well, what happens if that action was never triggered? That's what the application looks like. And actions can also be things that happen so they can be user inputs or they can be things that come from outside the outside world such as a network response coming back. So I can look at here, for example, and say, okay, once the data comes back, this is what it looks like. But what happens if that network request never completed? Then my application's in the loading state. So although the structure there is slightly different from Elm, the core principle is that the bit in the middle, your code, the part that you write is pure, which means you can replace it without losing anything. So there's three basic ideas behind Redux which enable all this. So the first is that you store, rather than storing your application state spread across a bunch of services and components, instead it's ultimately all stored in one place in a single immutable object. And that object is separate from the logic that updates it. I mean, just having this structure enables a lot of useful debug tools on its own. So for example, there's still on the right hand side here, that's something that's very easy to create. Once you have all the state in one place, it's very easy to create a tool which visualizes it, for example. You can then also, if that state is stored as a plain object, then it's very easy to persist a local storage or some other source. Or for example, if your application crashes and you're trying to work and you're trying, normally you might have had the experience of reading a bug report and trying to work out, well, what happened when it crashed? Well, if you have all your state in one object and if it's something you can serialize easily, then you can just send the state of the application along with a bug report. And because it's immutable, the library enforces it, there's only one way to update the state. So you can't edit properties on the object directly, instead what you have to do is call this dispatch function. And the dispatch function will take, takes in as input an object describing something that happened. So an API request completed. I set the repository that I want to want to see, et cetera. And the library then takes the state and then feeds it through a chain. It then feeds, it then gives it to what's called a reducer, which is the update function for the component along with the current state. So here, for example, I initially start out that I have no repository selected. And then when I type in the name of a repository and press enter, that passes the action, the set repository action will be passed into this function together with the current state. And the output of that is the new state of the application, which in this case is the same as before, except that for whatever chart I clicked on, the state gets the chart has been set. So straight away, if we have our application built like this, and if we have our components storing most of their important state, not necessarily all of it, storing their state in a reduc store, that gives us a very poor man's way to do hot reloading. So a redux data store is when you feed an action, when it updates the state, you can subscribe to those, you can subscribe to those changes. And then you could, for example, store that in local storage. And then when the application reloads, you could then reload that state out of local storage. So it actually functions there in the same way as the URL does in the browser, except that whereas the URL is just a string, so you have a path and you have query string parameters, here you could store something much more sophisticated. And the other nice thing is because our update function is pure, if we make some changes to the way that the application responds, so supposing when I click set repository, we change that the way that we add a bunch of other state that's updated, maybe for example, I want the application to zoom into that chart. Then we can change that logic and that can be hot reloaded as well, because the application can record all the actions as I perform them. So this list of actions here, it can record all those actions as I perform them. And then if we load, let's say it's a new version of our logic in, which responds to these actions, then we can just replay all the actions and then that would get the application to a different state, depending on what the current logic specifies. So that's hot reloading with Webpack React Redux. And the question is, can we make use of any of this at all with AMBA? And the answer is yes. Redux, fortunately, is a very small piece of code and the nice thing about it is that there's nothing magic about it, which means that it's very easy to integrate into, it's very easy to integrate into different JavaScript frameworks or no framework at all. As I said, it's largely to some extent a design pattern. You can apply it without even using the library. In the case of EMBA, there's a library called EMBA Redux. And the value that provides is although you could use them, although you could use Redux directly, EMBA Redux provides a convenience, essentially a set of convenience functions for connecting a Redux data store to a Redux data store to an EMBA component. And by connecting, what I mean is, we have our store and it has a bunch of state object in it. And it also has a dispatch function which you use to pass in actions to the store. And in EMBA, those map quite nicely to EMBA, we want to, usually, in our EMBA component, we'd have a bunch of properties and we want to extract various pieces of the state and somehow feed those into the properties on the component. And likewise, when we trigger actions on the component, we want to feed those back into Redux. So essentially what EMBA Redux does is provide convenience functions that connect those two. So this is what a very simple EMBA Redux component might look like. So this is taken straight from the QuickStart example on that page. But what it does is we create a simple component which doesn't know anything about Redux at all. It is a normal EMBA component which has a number property and a button below it. And what we do instead is EMBA provides, so EMBA Redux provides a function called connect which wraps that component. And the wrapper then extract, the wrapper takes a couple of functions as input and what those functions do is they extract the state from the relevant state from the store and feed it into the component. And when you perform some action on the component, it then routes that through back to the Redux store. So quick summary, hot reloading is a great tool for productivity, but I think there's a lot more that's interesting about the app architecture that you need. So the app architecture that you need to enable hot reloading has a lot of other benefits as well. Various people have built all kinds of debug tools with it. So I think there's a lot of reasons to use it whether or not you actually have hot reloading working. There are various libraries and frameworks and tools and languages that apply this design pattern. Redux is one solution, it's the most popular and it's something that can be integrated with EMBA. Thank you very much.