The Hard Parts of UI Development

JS Virtual DOM User Interaction

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 "JS Virtual DOM User Interaction" 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 incorporates user input into the virtual DOM example. The handle callback function responds to the user interacting with the input element and updates the data in JavaScript. When the updateDOM function is called, the DOM is reconstructed with the updated data.


Transcript from the "JS Virtual DOM User Interaction" Lesson

>> Now, I update DOMs off the call stack, user takes action. Let's get the user taking some action because it's time people for some user input, and the thing they're gonna do is type. So why we're having the user type and they are gonna type, let's have them type Y.

So then I only type y, y shows up, everything in green is user action, value is updated to y. As our friend online said, hold on, excuse me, why do I need to then update a value? Well, right now for our benefit in terms of structure of our code, see there's only as a brief submission by the user to please go update the JavaScript data.

And then assume once it's updated, here our giant converter will throw that all back, our VDOM will evaluate to a full description with this inserted and evaluated, and display update, what the user sees. How do we have that happen? How do we even trigger JavaScript code to run from user action?

Via a handler, our function handle here, using the incredible event feature of the DOM, the vital feature, if you're not allowed to run code directly in C++. And regardless, when you don't know when a user's gonna take an action, you need to have a structure whereby you can trigger code to execute, which we do.

And so this was already off the call stack, sorry. And now talk me through, who's, I don't know. Well, all I wanna know is why, talk me through? Sorry, why? Talk me through, what's gonna happen?
>> The function definition handle gets put onto the callback queue.
>> Beautiful.

>> Gets pulled off of it and put onto the call stack.
>> Yeah, absolutely.
>> Gets those pink parens.
>> I love it. The pink parens representing our friend JavaScript, taking a lead here and adding those, there they are. And -.
>> The thread will then invoke the handle function.

>> I love that, yep. And create a new what, why?
>> Execution content.
>> Yeah.
>> [LAUGH]
>> Exactly. And it's really basic what it does because all it's gonna do is update data, it's not allowed to do anything else, so taught me through that.
>> Yeah, absolutely.

It goes to the JS input accessor object, looks up the value key or calls the getter setter method.
>> Yeah, even now it's worth being as crisp as possible, exactly which is gonna retrieve what value?
>> That string, the letter Y.
>> Y, exactly, which is gonna be saved as a JavaScript string into our global label, our global data name, is that right?

Yeah, perfect.
>> That is the only thing that happens in response to the user input.
>> Perfect.
>> But 15 milliseconds later.
>> Exactly. So it handles off the call stack, it's finished doing its only job from the user, and these again are not trues, they're just approaches.

There you go.
>> [LAUGH]
>> They're just approaches to thinking about how to structure code when it is so with two elements, tricky to follow the flow. But I can think we can see with two elements at least here where we have a full description and the data is anything the user can change, full description being this array here.

Well, the description, I guess is generically in the code, but it evaluates to a full data-driven description here in the actual memory becomes a lot prettier to track your head around, I think. So as you say, why have I update DOM? Tell me what's gonna happen there. Please do keep interrupting me because you're doing a great job.

>> Yeah, absolutely. So yeah, 15 milliseconds later, we get the update DOM function put onto the callback queue and then immediately brought onto the call stack, assuming there's a user interrupts. From there, it gets the pink params, it gets invoked.
>> Yeah, you are doing a great job.

Brilliant update DOM
>> Should I go into the update DOM?
>> Yeah, let's do it. And if you want to leave the chorus, I said just go ahead. A brand new, everybody.
>> Execution context.
>> Exactly. For people who are bored of that online, I really don't blame you, simple pleasures for me, I suppose.

There it is. There we go. So update DOM brand new execution context, first thing it does is, well, keep me going actually while you're helping my brain here. Thank you.
>> It invokes the createvDOM function and then assigns the return value to the closure in VDOM variable.
>> Yeah.

Well, we're not closing in here, right, we're doing the global, we're avoiding doing anything. Did you say closure? Yeah, exactly. We are not having to deal with that, we're doing an in global for everything. So it's gonna reassign, it's gonna wipe this, we could archive this. Imagine we archive this, then we'd know exactly what changed between our two different states, the two different user actions cuz the only way that a user actually can affect is via state.

So we'd have a full history in every version of this. That's kind of cool, right? And what if we can use that at some later point, but for now, let's just get rid of it. A bit wasteful of us, but I feel like we could definitely use the information there about what actually changed in terms of the real page, but we're not going to.

So we're gonna reassign to vDOM exactly as before, it's gonna create that array of arrays. This time, it's telling me the evaluated result of it based on this data where name is now y.
>> It gives us a two-dimensional array?
>> Yep.
>> The first item or the zero index item is an array with the items and the string input name which currently is just the letter y, the string.

>> Exactly. And -.
>> And always difficult isn't with user actions, it's not in the code, it's an outsider system input, and it came in here with the string y, perfect. And then -.
>> And then the final item in that first array is the handle function.
>> Brilliant, which the way we wrote our convert, will then become our handler.

And that's just the way we wrote our convert function, and true about this again, it's just the way we did it and then
>> And then -.
>> And then the second and final Item in the array is another array with two items, the first, the string div.

>> Yep.
>> The second is the interpolated string, hello y.
>> Yes, exactly. We don't leave it as just a template literal, we evaluate it, and therefore, we get a real data updated rendition of what's gonna show up on the DOM itself. Beautiful. We're able to do that because there's nothing that's gonna be here that isn't described in JavaScript based off our states.

So, we have done why our createVDom call that has reproduced our description with the latest data in JavaScript. And so why, what do we do with that updated description of our elements? To the way
>> We pass the first of the two items in the VDOM array to the function convert, and we'll assign the output of that to the JS input variable.

The convert function -.
>> Well, yeah, I'm sure we can do this by analogical way. Maybe not. Maybe not. Maybe not. Maybe not. What am I talking about? No, we're gonna do it in full. Now the whole thing. VDOM position 0 is at input y and handle, right?

>> Input y and handle function. Yep, perfect. And that's going to what? Or talk me through why you do a great job.
>> So yeah, it's going to create inside of the function a new JavaScript successor object and DOM node.
>> Yes, what did I say? Access to the object and DOM C++ associated node, exactly right.

That C++ is only the node, is it gonna be appended yet? It is not.
>> It is not, it is gonna be in this unattached area here.
>> The specific node type is going to be taken from the 0th item of the node param, which in this case is input.

>> Is input, perfect. So we took node 0 and used that to create a new element. I guess, we then also as you say, return out is all happening inside of convert. We then returned out into LM, the local label for it inside of this running of convert, inside of this execution context which we're not actually showing, because we're trying.

To some extent, we don't need to worry at this point, we can just rely on update DOM, basically, to update what shows up from here to here, but we're just gonna map through for our purposes. We're also then gonna have on our value here via the setting of LM using the value setter.

What are we gonna set our value here to be?
>> And for that we're going to set it to the string y.
>> y, from our memory, so it's gonna be in white. And then we're gonna set our input handler, again, all happening inside of LM, where we're doing now the onInput setter and assigning node position 2, which is our what function?

>> It's our callback function.
>> Which is called what?
>> Sorry, handle.
>> Handle, beautiful. Exactly, our callback function is a generic term, for you're exactly right. Perfect. And in JavaScript, we got a link, my goodness. We got a link to it in JavaScript, we got a link, so this deleted this object, brand new one.

All right, I'm not gonna draw out again, I reckon. Let's have it just go to this new input, beautiful. But this is a brand new object, the last access object gone. Okay, by analogy, we also created what here, why in our DOM in line 13 where VDOM position one has div hello y.

What's also gonna show up here in our DOM?
>> By analogy, we're creating an element using the node 0 which is div.
>> Yeah.
>> We are going to assign it text content.
>> Of?
>> Hello, y.
>> Beautiful, yeah. Hello, y! And we're gonna get what here to replace this JSDiv object?

I'm just gonna do it this time rather than ask the question for so long. And create what in this object as the output of running convert VDOM position one?
>> Another JavaScript accessor object to be able to interact with the -.
>> Beautiful, with useful properties like text content.

And a hidden link to this div. Perfect, and then this is a getter setter property that could be used as we did use it inside of convert when LM was the label for this object before we returned it out from convert into jsDiv on our latest running update DOM where we didn't even actually write the convert here, but we know it was just run by us.

We just talked it through, and there it is on VDOM. And then in line 14, why, what happens?
>> Finally, we call the replace children method over the body object of the document object exposed by window and we're passing it jsInput and jsDiv.
>> Beautiful. And what's that gonna do on our actual DOM?

Because that's where this is happening, that's going to replace our linked elements, it's gonna replace our former now unlinked elements with what? Why?
>> With the two newest versions of jsInput and jsDiv.
>> Linked here via our access objects, these are replaced and actually deleted because, did I lose the, these are replaced and actually deleted, therefore gone, gone, gone!

And we get a link instead, we get attached instead input and div, so not a link but attached instead input and div, that then immediately show up on our page with the y, the user never knew what happened. Albeit, we had to refocus the element. In practice, we'd have had an end of our update DOM after the replacement.

jsInput.focus invoked to make sure the cursor was back in here so the user wasn't frustrated, they typed, and then it's bounced out. And then our div which says Hello, y! People, let's give a big hand. [APPLAUSE] Yeah, absolutely y. Beautiful, absolutely outstanding technical communication. So I mean, for everybody, but that was excellent.

We ended up with in JavaScript a visual representation of what was the show up on our page. We then had our state, add data run through it every time the data changed such that we had a visual representation with actual accurate data in JavaScript, which we by the way could have archived and maybe use the changes between it in some way, before that then gets rendered displayed on the page through our convert functions.

For the first time, you have a return of descriptive code that describes its output in JavaScript. And we're very lucky to have it. [LAUGH] Yes. It depends on the the restriction of the user only gets to see things that are a direct consequence of underlying JavaScript data. There is nothing on here that is not captured as a consequence in our update DOM converter.

Well, actually, sorry. Where are we describing the relationship between the data and the view now? Well, whatever. Alexa, where are we describing the relationship between the data and the view?
>> In our VDOM.
>> In our VDOM.
>> Exactly, in our array. Exactly, that's now a very visual description of what we were previously doing, it's really cool, then we use the actual process of turning that into elements imperatively.

The descriptive process in the, well Alexa, in the which function?
>> Convert.
>> In the convert for each element. And so we now finally, but it does rest on every single thing the user sees. We could totally write code by the way in this VDOM creation that says only produce div based on some sort of conditional logic, a ternary could evaluate right there.

That's kind of cool. We can have our full description of the element, its handler, its content in that list, but that requires that everything the user sees always is a direct consequence of state of data in JavaScript. Meaning the user can only have consequence of what they see via a handler function that only changes state, and then we pipe it back through to display.

All right, people, there we had it, we got a couple of thumbs. A virtual DOM, I hope it even seems a little bit, that's it. Blocks of code representing each piece of view. We could create them with functions, we could have a function called to create that block of view, and we will.

JavaScript array, in this case, of all the details and a function that takes in that array and produces an actual DOM. And that's our convert function call that we went from doing in full, to doing somewhat, to not even writing it. Because to be honest, we only think about it because it's all described for us here.

Isn't that kind of nice? And then where we place the elements in the code mirrors the order they show up. However, as we saw in arrays earlier, not very flexible right now, is it?

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