The Hard Parts of UI Development

Updating DOM Elements with JavaScript

Will Sentance

Will Sentance

The Hard Parts of UI Development

Check out a free preview of the full The Hard Parts of UI Development course

The "Updating DOM Elements with JavaScript" Lesson is part of the full, The Hard Parts of UI Development course featured in this preview video. Here's what you'd learn in this lesson:

Will walks through the flow of data when JavaScript is used to update the content on the page. JavaScript APIs pass data to the C++ DOM list through the WebIDL abstraction layer.


Transcript from the "Updating DOM Elements with JavaScript" Lesson

>> So let's now use the fact that the real jsDiv is not this, that we've console.logged and saw, but instead is an object with a method that has access to the C++ DOM element, and so with that in mind in line four. In line four, here we go.

We are going to access jsDiv. That's not very good, is it? Let me get this right. Let me get my wording right. So here we go, what is post? Ian, what is the value of post here?
>> The current value is the string high and exclamation mark.
>> Beautiful, beautiful, perfect.

We are going to try to attach to, we hope, the DOM element, the string high. Well, here's already a tricky question. jsDiv is our object that has a property text content. I kept calling it a method, maybe you can think why. Cuz if that were a regular old property, Ian, can you help me with this?

Where would that high be assigned? If I had jsDiv.text content equals post, which you just said is string high, where would that high be stored on that jsDiv object?
>> If it was a regular old JavaScript object then it would get stored as under the key text content in the object jsDiv.

>> Can we just give Ian a round of applause for a really sharp-
>> Really sharp communication, Ian, that's really, really good. Yeah, which is of zero use to us, right, because now great, now we've got high in JavaScript, where do we want it to go, Ian?

>> We probably want it to go out to the DOM.
>> Yeah, beautiful.
>> And by extension show up in the UI in the browser.
>> Beautiful, wow, Ian, excellent, excellent, exactly right. And it does, because in practice, text content is working to do this. One, it goes and looks at the link.

In this case, it's a link to which element, Ian?
>> It's a link to the jsDiv.
>> Yeah, so jsDiv is our JavaScript label for it, which has a link to our DOM Div element, spot on. And then, we are going to take the value of post which is high, and we are going to set.

So a property that acts by running code under the hood to go and do something else, even though it looks like a property, you can call a getter setter property. It is in this case going to set the value or the text of this DOM element to be set text in C++ to be the string high from JavaScript.

And now exactly as you said Ian, high shows up on the page. Beautiful, flipping heck. We've now managed to display content, one second, Paul, we managed to display content that would have taken us one line in HTML. Honestly, actually, we didn't even do the, yeah, it would have taken one word, one letter.

Three letters, we could have just written high inside of that div for it to show up on the DOM. Do we start to see why HTML is such a magically intuitive language and how JavaScript is so rough? However, it's gonna give us fine-grained editing control. It's gonna give us fine-grained editing control over what we can do to these elements, and the ability for us to change data in JavaScript and then change what shows up on that list of C++ elements.

Wouldn't it be wonderful if we could write C++ directly there and do it rather than have to access it through a bunch of slightly quirky JavaScript [INAUDIBLE] and created. And I call this an access object that has a hidden link to the DOM element in C++. By the way, people, especially folk online as well, you might be thinking my God, do I need to know all this?

Well that's a separate question.
>> [LAUGH]
>> That's a more deep question. But you might be thinking wow, this is a heck of a lot just to put some content on the page. However, it does turn out that once we have this model down, this is the model until the end.

As I said, there are four parts to UI hard parts, part one is the truths. Part two, three, and four are moves to make the truths more easy to work with. Yes, it's my new quote. It is demanding, however, once we have it down, it becomes the standard.

Let's have thumbs on this, I wanna start seeing clarifications. Excellent, John's got one, Justin is clear. Paul's got one, fantastic, Phil, Alexa, Wyatt, all clear. Let's start with Paul, you had yours first.
>> It's not a big deal but you put the high in the wrong box there, you put it in-

>> No, honestly, Paul, thank you. Everybody is grateful for you doing that, thank you, because otherwise that would have been let. Can we do a round of applause for Paul? [LAUGH] [APPLAUSE]
>> Yeah, yeah, thank you, Paul. Honestly, for me, that makes me appreciative you're following it so closely, fantastic.

What else was I gonna say? Yeah, why do we need to even know this? Well, flipping it, we're gonna see in a moment that the fact that these are in two different places. Our data is in one runtime, and the structure that persists displaying that data and directly mirrors what's on the page is in an entirely different runtime that we access, by the way, on a case by case basis.

We're gonna quickly see there is no way to have data, well, I'm not gonna give it away, but wouldn't it be nice if we could have changes of data here flow directly through to here? These are two different runtimes that we're gonna have to manually make the moves across to change.

Because you might be like, well do I really need to know this? Unfortunately, having your data in a different environment to the structure of your page where that data ends up being actually displayed, and when the user changes, the data is gonna change here, but you've still got data over here, that's gonna turn out to be profoundly challenging.

It's gonna be why we impose such strict rules on ourselves to make things at least as predictable as we can make them. But also, what was I gonna say? Yeah, but also, my goodness, the web browsers doesn't half make it hard for us to realize this. When you have the console logging, the HTML that created the DOM element in C++, when actually you're logging the JavaScript accessor of that.

I mean, that couldn't be more misrepresentative, right.
>> [LAUGH]
>> All right, John, you had one.
>> So I had a question about the call stack. So document.querySelector is being pushed to the call stack or?
>> Good question. Yeah, technically it is. I think the reason I'm always hesitant to put it on the call stack is it implies, it's code in JavaScript being run, right?

The question, I guess, becomes where does the JavaScript execution here end and where does the C++ code begin? Well these bits are going off to access C++. Don't forget, JavaScript is technically running within a browser in C++. So actually, you can think of that handling when tasks go out to other parts of the browser under the hood and when it's actually just JavaScript code running.

I don't ever put it on the call stack, although it is on the call stack, because I like to think of the stuff on the call stack as being the code that we have written and that we are taking the threat of execution inside of. And that we could actually change the code inside the functions that are on here, whereas we can't go and change querySelector.

But yes, as a JavaScript function, even though it's actually doing a bunch of work outside, it technically will go on the call stack, yeah. Great question.
>> Do all script tags refer to the same JavaScript runtime with shared memory space and etc?
>> We'll see that in a moment.

Actually, this is the second one where we're gonna come and see this, once we start building out our own version of the DOM. So let's hold the ones around how JavaScript runtime works across different, these are ones which become interesting. So when we think about hard parts, it's always intellectually fascinating to go deeper, right?

But I do always like, I don't really know what this quote means, but the turtles all the way down quote, which is, you can always go a layer deeper. The question becomes, is it helping you understand building what you're doing today. We are not doing this for the sake of the intellectual satisfaction, although to be fair, we sort of are.

Only because, I want also you all to be able to go to your interviews and say to them, you're gonna by the end of today, even by the end of today, maybe by tomorrow, be able to say, I prefer to spin up my own custom implementation of the virtual DOM.

>> [LAUGH]
>> Let me try that again.
>> [LAUGH]
>> I prefer to spin up my own custom implementation of the virtual DOM. And by the end of tomorrow, did I miss part of it? Okay, I know you can't do it yet, because you don't prefer it yet but soon you will.

>> [LAUGH]
>> But soon you will, once you do, you'll be able to say that. What I'm getting at there is this stuff is incredibly important to understand the great UI frameworks, the reacts, the felts, the views, the angulars. I should have had this at the start, sorry, people.

Under the hood, such that you can debug them, such that you can work with them at scale, such that you can even genuinely spin up your own versions of them. It's for that purpose. However, it is also quite cool to be able to go into interviews, and speak to some of these things.

Because the senior engineers, the VPs, whatever, interviewing you, to be able to tell them these sort of things, they may have come to these over years of kind of piecing it together. But for you to be able to give them these mental models, honestly, it's a cool edge.

Listen, I'm not saying you wanna intimidate them, I'm trying to be polite, I don't want to have on record.
>> [LAUGH]
>> I'm not saying you wanna scare them, but I am saying that you want them to come away saying, uh-oh, my job is on the line. This person's knowledge is, I don't wanna, see, that's not very nice is it, but that's the goal.

So in terms of the question there about JavaScript runtimes and/or how between different web pages and within a web page JavaScript is executing, we'll see later on from a place of why, how that works. The reason I say that is each of these pieces we want to introduce as ultimately enabling us to do something, not for the sake of just intellectual knowledge.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now