Update the DOM on Data Change

[00:00:00]
>> So we had even more composition, creating multiple similar virtual DOM elements, each with different data, using what we saw there, our post function, that's our functional component. Now, all of this, though, becomes untenable in terms of our performance. For each of our changes in data, while we as engineers get to reason in an incredibly intuitive, honestly, actually for UI engineering, pretty intuitive manner.

[00:00:30]
Let's go back to this example here, pretty intuitive manner here. We get a list of described elements, line four through six, which then when the data is set initially and ongoing it's changed generates the latest full description with that data of what's to be added to the page.

[00:00:51]
The DOM, the C++ element that then shows up on the pixels itself, it's pretty, as far as it goes, intuitive. One place, createVDOM, that describes what's to be displayed on the page from JavaScript. Can you imagine we got that from JavaScript, the language that screen please don't have anything that looks anything like what's gonna show up on the page, we really don't want it?

[00:01:15]
We managed to get that, however, at a cost. The cost being, we are keeping things simple, but we are replacing all of our DOM elements in C++ on every change of data, we are producing a brand-new description of the page. And then we are keeping it simple, converting them each one by one into actual DOM elements.

[00:01:41]
But wait We know from our virtual DOM, our visual DOM, our JavaScript description with all the data funneled through it, we know exactly what is to be displayed. We also know from the previous data before we had Li, we had an empty string, we also know exactly what's being displayed there.

[00:02:01]
What if we were to somehow use the actual differences between our JavaScript arrays to determine, not just wipe the whole thing with brand-new elements? But to write some sort of code that actually only creates the elements from scratch on the first displaying. And after that, just switch out the specific content changes as needed.

[00:02:25]
We don't get to think about that though, as developers, we just do our same thing. Describe the relationship one-to-one and write the handlers that change the data. And then we had to do it here, I didn't even write it out right. I did Pseudocode because it's just the same thing without, well it's actually just a representation of what's in our VDOM.

[00:02:42]
Just the same thing wouldn't even be enough, it's just a representation of what's in our JavaScript VDOM. So we are going to be able to fix our performance issues. We love the visual virtual DOM for its semi, semi visual coding, however performance is a nightmare. It always reminds me of a Michael McIntyre skit that means nothing to anybody in America.

[00:03:05]
We need some improvements, we're updating our DOM every 15 milliseconds, handlers, CSS animations, and smooth scrolling. So we've got two problems actually here. We're also doing our update DOM that is creating that bond between the data and whatever's that's displayed without, I'm gonna think about running it. Instead, it just runs whenever the date, well not whenever the data changes just whenever, at all times pretty inefficient.

[00:03:32]
Can we simulate the auto updating view from data change with a state hook? I hope so, and then finally, only to have our DOM elements need recreated from scratch. We can compare, with diffing algorithm, an archived version of the virtual DOM and work out what changes to actually make using an algorithm, which is clever code.

[00:03:52]
It's not gonna be too clever, but clever enough, so here we go, automatic update on data change without looping. So we're gonna use our existing diagram here just to make some tweaks, so rather than look down the line 29 there rather than having update DOM run on repeat with set interval.

[00:04:12]
And we could perhaps have update DOM run recursively using request animation frame, we'll see in a second. But rather than doing that, we are gonna have update DOM only run when our data changes. I don't wanna be back in the land where I'm not guaranteed that what's in here is directly represented on the page because I changed my data and forgot to run update DOM.

[00:04:40]
I know that sounds obvious, like I should remember. I don't know that date is changing in many different places and I got like every single time update DOM? There must be a better way, there must be a way in which I could wrap up my changing of my data and a rerun of Update DOM into one composite task.

[00:05:03]
How do I wrap up two lines of code into a composite task, Alexa?
>> With a function.
>> With a function, exactly right. I'm gonna simulate, give the impression that all I'm doing in this case when I run my handle function and update my name from empty string.

[00:05:20]
In this case, it was via the user input to Li, that I am gonna do that through a function that will update my name. And when I call that function update name, I'm gonna pass in, in this case it would be Li, not assign it directly to name.

[00:05:38]
But pass it in, where I will then assign Li to name and then run update DOM again. So now update DOM is whenever my data is changing is going to run, but I'm not manually doing that. I'm just restricting developers on my team to only be allowed to change state change data in JavaScript through a function that updates my data.

[00:06:04]
And also low-key behind-the-scenes updates, runs my update DOM function. Let's generalize that a little bit here with this code, and we're gonna generalize that to work for any data in a second. But yeah, automatic update on data change without looping. Instead of directly updating name, we can run a function update name to do so.

[00:06:28]
And of course it's low-key running update DOM for us behind the scenes because we wrapped two lines of code in one with a function. As long as we restrict our team, and we would do that via obviously with some sort of closure that locks down access to our data and ensures you can only change it through a function.

[00:06:48]
But that function is also low-key running the update DOM function, which we've been running automatically. Ensuring any change of data automatically populates a JavaScript representation. We don't think about when it changes, it just changes. It's happening so often it's been repopulated every time and also, most of the time when data hasn't changed, that's a ridiculous thing, that was super inefficient.

[00:07:09]
We were recreating with every single time unnecessarily, right? We do not need to run update DOM 60 times a second, where the user didn't even change the data, [LAUGH] that was pretty spurious behavior. And so instead we're gonna bring back only running update DOM that creates the JavaScript representation of it, that creates the underlying DOM elements in C++.

[00:07:34]
Only do that when data actually changes, but I don't wanna be thinking about, data change, make sure I re-update my page. No, that's back to the old, it's not terrible, it's just it's not ideal, I'd rather not have to do that. How can I get around that? By creating a function that both updates my data, and low-key also reruns my update DOM function, that does the job of converting that data into the JavaScript representation with create DOM call.

[00:08:01]
And then maps over creates all the associated elements in the corresponding items in the real DOM. And then we get our accessor objects that allow us to append or replace the existing elements with those new elements and they get displayed.