Transcript from the "Update the DOM on Data Change" Lesson
>> 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: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: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: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 dishing out an archived version of a 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 youth input to Lee, 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 Lee, not assign it directly to name.
[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 jobs 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: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 jobs 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 access to objects that allow us to append or replace the existing elements with those new elements and they get displayed.