Diffing Algorithm

[00:00:00]
>> I'm gonna run my findDiff function with passing in previous vDOM and vDOM. There they are, previous vDOM and vDOM and create, I think it's our last one. Create a brand new one what everybody?
>> Execution context.
>> There it is, execution context. We're still inside of update DOM, so it goes on top here, right?

[00:00:36]
Am I right on that, yeah?
>> Yeah.
>> FindDiff, There it is, into it we go. And i is 0 initially, and we are going to compare if the stringified version of all these are our two parameters, previous and current. Previous refers to previous vDOM, and current refers to vDOM.

[00:01:10]
And so we're going to say if i is 0, stringify, that means turn it into a string previous vDOM at position 0, that is going to give us the string what roughly Phil?
>> It would be the string of-
>> Roughly inputs and then-
>> Input-
>> And then sort of the words function or whatever, I think.

[00:01:33]
>> Yeah, and then likely the code for it.
>> Yeah, exactly, exactly, exactly, yeah, yeah. And then now we do it again for current, which is what, Ian, current is our vDOM, and we're at position i of 0. So, we're going to get a stringified of that, which is what?

[00:01:57]
>> Input FM.
>> Input FM function.
>> And the function should-
>> Okay, are they the same? No wait, are they different?
>> Yes.
>> Yes, they're different. There it is, they're different! And so we are now going to grab current, position 0, the text content, so the content basically, the input value.

[00:02:24]
And we're going to grab that current, position 0, in that sub array again is 1, which is the content because we're gonna assume in this simplified model that we can only change our content. But yeah, we could easily expand this to handle all and any changes to what the user sees.

[00:02:45]
And set that FM to elems position 0 using our text content, uh-uh, no, no, no, we're gonna skip that one we don't need to, because it's an input. It won't cause any breakage, but we're going to hit our, this is again me trying to make sure we do not set a bunch of conditionals to work out what type of element it is, but we could very easily change that.

[00:03:09]
And here it doesn't actually break anything, because we're gonna hit value on our elems position 0, which is our setter, in this case to set on our associated corresponding element here. We're gonna set input value to, and look, incisive edit to FM. Did I get that right? I literally, and immediately it's gonna show up here on the page.

[00:03:43]
Okay, let's do another comparison people. elems position 0 is going to have its value setter set to the value of FM. We know it was FM already, but we don't have to reason about any of it. All of this, by the way, it's update DOM is being done by JavaScript because we have a update DOM function created.

[00:04:06]
All we're doing is honestly changing, all we write is changing our data and then funneling it through with our beautiful description in JavaScript of what's gonna be displayed. I know we're going through the rigmarole of doing it ourselves, but yeah, and then final, or no, penultimate comparison. Ian, if you don't mind comparing our stringify here on i is now one.

[00:04:32]
>> Okay, so we'll be comparing the stringified first index of prev vDOM.
>> Right.
>> Which is going to contain div.
>> Yes.
>> And hello exclamation mark.
>> Brilliant.
>> And we're comparing that with the stringified vDOM 1 at index 1, which is gonna be div Hello FM!

[00:04:57]
>> Brilliant, is that different?
>> Yes.
>> You bet it is.
>> Yes.
>> It's definitely different. And so we're going to do elems position 1, and set, in this case its text content. Again we can, this code works because text content is ignored by the input DOM element and value is ignored by the div DOM element.

[00:05:18]
So text content setter, my goodness, elems position 1 is our access object for the div element, where we are the first element where we're gonna set its text content to, what Ian?
>> It's going to become hello, FM!
>> And there it is, we as developers didn't think about any of it, but it's already made the incisive change.

[00:05:54]
We just went, describe what it should look like on the page. Describe it, and then if the data changes, you do the work here with the diffing. And the final one, would it fit? Maybe. The final comparison, Alexa, is going to be between? I's value is 2 now and so we're stringifying position 2.

[00:06:17]
And what are we comparing?
>> We're comparing div great job, to div great job.
>> And are they different?
>> No.
>> They are not, let's say it everyone together. Are they different people?
>> No.
>> No, so do we go and do any changes to our DOM element?

[00:06:36]
>> No.
>> No.
>> [LAUGH]
>> I think we did it.
>> [APPLAUSE]
>> I think we did it people. Have I missed anything here?
>> Look at all those CPU cycles we saved.
>> My goodness.
>> [LAUGH]
>> What a beautiful job everybody, that is our update DOM function finished running.

[00:07:01]
We exit our findDiff execution context. We exit our update DOM execution context.
>> [LAUGH]
>> And We have made our changes and we got a beautiful, simple, I guess simplistic even. No, not simplistic, a beautiful description in JavaScript of what we want to display on the page with dynamic data, imagine HTML but you could have variables in it, which is what we're always trying to get to.

[00:07:33]
That's all we've been trying to get to, punchline. Descriptive of what's going to show up on the page, but with data that can change. Because what are the two things user interface is trying to do? We're trying to, what are we trying to do? Display, one, what's the first thing?

[00:07:47]
>> Display content.
>> And two, is to let the user.
>> Change the content.
>> Changed the content, change it, exactly. Yeah, yeah, exactly. So we had with HTML beautiful techniques for displaying content, put it on the page in the order you wanna display up, display in. And if you went to inside or something on the page, put it inside of that stuff in the code.

[00:08:07]
Display content, it was easy, but we didn't have any data. And there's no such thing as content being changed by the users action. And what they see changing without there being associated corresponding data. Unfortunately, that data lives in a totally different runtime, that of JavaScript. And the flow back and forth, particularly given there's also kind of persistent state here in the DOM, the flow back and forth was extremely hard to maintain mentally.

[00:08:35]
So instead we said, one simple rule, users can only in their handlers update or we as developers can only write code to update underlying data, and then have a single function flow it through. Only think in terms of underlying data must describe all view all stuff the user sees must have corresponding underlying data.

[00:09:01]
Such that we can see exactly where our consequences, exactly what our change is based and caused by the underlying data flowing through to the view. It's one way of providing that restriction that makes our code predictable. I know where my output on the page comes from. It's my single function running through from underlying data.

[00:09:26]
I don't have to reason about if the user clicks on that, then swipes that, then given all those things, I'm gonna change. No, no, no, just change data and based on that data, display content, almost see it as a submission, and then based off that display it. What that also gave us was the ability to describe as an intermediary step in JavaScript what content we wanted to have displayed of that data.

[00:09:54]
And we did exactly that with our visual or virtual DOM. It allowed us to only think in terms of one description and a bunch of conditional displaying of the underlying data, including whether or not to display divs, whether or not to display content. And then we realized we were still wiping our entire DOM, as though we didn't have a full archivable history of what was actually gonna be displayed on the page in our JavaScript.

[00:10:27]
Where we could then compare those two collections of elements with their instantiated data and decide what actually changed, which we did. And from that diffing, that algorithm that did the comparison, we only made the actual changes necessary to the real C++ elements. No performance issues.
>> [LAUGH]
>> Finally, composable UI, that's not a disaster.

[00:10:59]
Integrating that diffing algorithm makes our code for building user interface semi-visual. There it is, described on the page, looking like what it's gonna be in the output. But not untenably inefficient.