The Elm Architecture: Update

[00:00:00]
>> Richard Feldman: So let me get the question of, we have this goal of transitioning between these two states. Like over here, I've clicked the popular tag of elm, and over here, I've clicked the popular tag of programming, and we want the page to look different in those two scenarios.

[00:00:13]
So how can we get it to look different using this one view function? Well, basically, this question boils down to, how can we transition from the initial model to a different model that has a different tag selected. How do we get from the one to the other? Because if we can do that, as long as view is capable of rendering a different thing based on which model it gets, as long as we can transition from one models to the other, and have you get called again with the updated model, then we should be good.

[00:00:44]
It should successfully render the new page as we want it. So the link between these two, that causes that transition to happen, is called update. So update is another function, much like view, and it takes two arguments. So one of the arguments is the model. Same thing as view.

[00:01:01]
Model represents the entire application state. The other argument is called message. So essentially, what the message does, is message is something that comes from the outside world that tells update sort of what happened recently, and let's update figure out what to do. Ultimately, what we want update to do here, is to do something like this, this record update that says, I wanna take my model, and keep everything about the same, except I wanna change the selectedTag to elm, because the user clicked on the elm selectedTag.

[00:01:32]
So this is going to return a new model, and that's sort of what updates job is, is to return a new model that describes the new application state. So whereas Views job, was to return a description of how the page should look. Updates job is to transition between application states.

[00:01:47]
It's to say, we started off at this state, but based on what most recently happened in terms of user interaction or something else, now, we want to transition to this new state. And the way that it does that, is it just returns what the new application state ought to be.

[00:02:01]
Message, is sort of the way that it knows what to transition to. This is a value that comes in from the outside world that describes what just happened. So this could be a user interaction, like for example, the user clicked on one of these tags, it could be the user typing something in.

[00:02:18]
Or it could even be, as we will later see, something like a message coming in from the server. Point is, a message describes something that just happened. Using these two ingredients of the message and the model, we can decide what new model to return. Here's an example of something we could use for message.

[00:02:37]
We get to decide the format of message, I've chosen this particular format. But we're actually gonna evolve this over the course of the workshop to a different format. But for now, this is a good starting point. We're just using a record, we're saying update gets a record for its message that has a description of clicks tag.

[00:02:54]
Which is sort of a pretty straightforward description of what happened. And then, it's got a little piece of extra data, which describes which tag the user clicked. So by looking at these two pieces of information, update can say, I see what happened. The user clicked a particular tag.

[00:03:08]
I'm going to change the application state to reflect that. The way that this is going to get into update, is by specifying it as an onClick handler in the view. So when the view is rendering or describing this button, that the user's going to click to send the message to update, here's how it does it.

[00:03:28]
There's a function called onClick which takes as an argument the exact message that's going to be sent to update when the click happens. And then, that's actually just a plain old attribute that we can put inside of our button. So just like we had class as one of the attributes that can go into button, onClick is another one.

[00:03:46]
Event handlers go in that same first list of attributes that get passed to every element. So button, onClick, and then a record. What this code does, is it means that not only are we rendering a tag button that has the text of elm, but also, we're specifying, whenever the user clicks this button, this message should get sent to update along with the current model, and then, based on that, update's going to potentially transition us to a new model.

[00:04:13]
It's gonna say, I am going to change our application state from what it was before, to this new application state, based on the message, and based on the existing model. So to see this in diagram form, we have our current application state, that gets passed into view, View render some HTML, which now includes some buttons with onClick handlers.

[00:04:31]
The runtime takes care of wiring all that up, all the event listeners, does all of that for us. When the user clicks that button, that says Elm. The runtime is going to send that message that we specified in our HTML that the view returned, as an argument to update along with the current model.

[00:04:49]
And then update says, okay. Based on that, I'm now going to probably do a record update to set the currently selected tag. And then, based on that, the runtime's gonna say, I see that update is giving me a new model. I will pass that new model to view, which in turn will give me some new HTML.

[00:05:05]
And the cycle begins all over again. Fundamentally, this is how every Elm application works. This is a complete way to describe user interaction and updating the screen, based on what happened. Elm's able to do this very quickly, fortunately, because one of the great parts about the Virtual DOM, is it's able to diff the before and after the description we used, rather than actually mutating the dom every time.

[00:05:31]
So when it gets this HTML from view, it's gonna say, I see that we have had this as our previous example of how the page should look. And then I see that based on the new model we have a new one, a new description of how the page should look.

[00:05:44]
It can very quickly run through those and just diff them and figure out, I see that. The only things that have changed between these two are, one of these tags is selected whereas previously a different one is selected, and also, some of the articles in the feed have changed.

[00:05:57]
And so, it will only make that minimal set of actual updates the real DOM, necessary to make the screen look the way that you want. So even though every time it goes through, it is building up a new description from scratch, it's not actually having to do all that work every single time the interaction happens.

[00:06:12]
So that's why Elm is able to be competitive in speed benchmarks to other libraries that are not using virtual DOMs.