The Hard Parts of UI Development

UI Component dataToView Function

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 "UI Component dataToView Function" 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 execution context of the first call to the dataToView function. The ternary operation determines no input is present, so the DIV element is yet created. The onInput handler is also established.


Transcript from the "UI Component dataToView Function" Lesson

>> It's done. And 50 milliseconds, people, here it comes at 50 milliseconds. [COUGH] We're gonna get at 15 milliseconds, what function is going to be called back, Alexa, into JavaScript?
>> dataToView.
>> dataToView, beautiful, and told me through if you don't mind, Alexa, the process of that. So dataToView is gonna go where?

>> In the callback queue. And then the event loop is gonna check if our global code is done running, which it is.
>> Perfect.
>> And if the call stack is empty, which it is. And then it will pop the data to view function off of the callback queue and push it onto the call stack.

>> Absolutely, fantastic. Yeah, there it is, onto the call stack. And pens are starting to struggle a bit here. Onto the call stack and that is where it's gonna create, Alexa, what?
>> A new execution context.
>> Exactly, a new execution context, which is going to do the job of displaying, how's this gonna do.

Gonna do the job of displaying, but we don't need that much. It's a nice, clean, simple function, it's gonna do the job of displaying our data for the user. Are we familiar with this now? Are we bored with this? Is this tedious? You bet it is. No, it's a big function.

Okay, I got that wrong. You should have stopped me.
>> [LAUGH]
>> There we go it's a big old function here. Because we're now doing anything that the user can see, is gonna be produced inside this function. And only produced if the user is gonna see it in that moment.

Through this mental model, this paradigmatic shift to anything user sees that they could not see or choose to change. Must be dependent on underlying data from a source of truth, from a cause, a single cause, which is JavaScript data in this case. A simple piece of data post.

And everything inside that data to view is basing itself off post. Even where it's not in line 4, implicitly it's saying produce input under any value of post. But we know it's all coming through this one function based off our data in JavaScript. Which is kind of cool, by the way, cuz it means we could potentially describe in full as an intermediate step.

Before we actually add those elements to the page, we could describe them in full in JavaScript first. And maybe end up with a visual representation of our DOM in JavaScript first, which would be kind of cool, kind of neat. Okay, I didn't need the word anyone's using. All right, let's do that.

Let's start running data to view, and bit more complex than we've done before. Well, not really, but Alexa, let's go through what the JS input assignment here is doing,
>> Yes, so we're gonna reassign JS input [COUGH] to the evaluated result of invoking our create element method on the document object,

>> Perfect, createElement, with what argument?
>> The string input
>> Perfect, input, there it is. And this is going to do, can you talk me through the stages inside of createElement here?
>> Yes, so first we're gonna use the document object's hidden link to find the DOM.
>> Link to the DOM.

>> And then we're going to create an element.
>> Yeah.
>> That is the type input.
>> Yes, perfect, we'll put it right here. It's not yet on our appended list of elements. It's not yet appended to the body, because Java Script doesn't really do anything, doesn't know where we wanted to put that element.

I'll give it credit, it doesn't know where we want to put that element.. HTML, we have a structure, it's gonna appear in listed order down the page, not in Java Script, we don't know where. And if it wants to be a child element or a sub-element or a nested element in HTML.

We put it inside of the element we want it to be appended as a nested element to, so lovely. Does that happen in JavaScript? You bet it does not. So, yeah, would be nice if we could get some emulation of that. Wouldn't it be cool if we could get some emulation of that?

In our JavaScript code, maybe a visual representation in JavaScript of the structure of our page, but that we couldn't do that. That sounds too much like a win. That sounds too, yeah, okay, all right. All right, good, so yeah, we create input unattached right now and we wanna be able to edit it though later, Alexa, right?

So what do we, help me out here, what do we get?
>> Also gonna get a JavaScript object with a hidden link to that new input,
>> Right,
>> Node on DOM,
>> Right, and also a bunch, yes, and also a bunch of functions that are useful for editing, updating, adding handlers to the input node, perfect.

Like on input like value, Yeah, so that object is then going to be stored in what? Global, again for the purposes of easy diagramming, what global variable.
>> JS input.
>> Perfect, there it is, so let's draw it in full there. It has, just remind me of the methods available on it here.

>> Value on input.
>> I think that's it, because we're doing a simplified version here. No, these brews are very challenging. There it is. And it has a link, as we said, to a newly created but not yet displayed input element on the DOM, input object. Note people here, we are now not seeing it immediately over here, we are creating it from scratch.

We'd end up with exactly the same thing as we would have by querying our HTML created version of this input element, nothing's different. But we've now created it from within JavaScript. Which means the only difference is now not already attached, and therefore not already showing up on the page.

To be fair, we don't know where we want it to be attached. We're gonna require, well, with JavaScript we're gonna require imperatively describing rather than declaratively by showing where it is on the HTML file. Describing its output, where it's located on the page. Instead we are going to have to imperatively in JavaScript attach it.

And describe where it will capture, specifically where we want to attach it, if only we could do better, hopefully we will. Okay, what's gonna be by now off? Yeah, talk me through what happens in line 5, Alexa.
>> So we're gonna be reassigning the value of JS Div, but first we have our,

>> Ternary, right, exactly.
>> Evaluate.
>> Yes, so if we check the first bit before the question mark and if it's true, then we assign the second bit. And if it's false, we assign the result of the last part of the ternary. So is the first bit true?

>> No
>> POST is an empty string, it is not well. So we jump to creating.
>> Yeah, we're gonna create a new element again, but this time it's going to be a div
>> Give me a div. Let's do it, that's created on the DOM directly. And we now I'm just gonna do it by analogy, the output of calling it.

I'lll put the value, what's the output of evaluating the document.createElement past the argument of div. What is gonna be assigned to the global variable jsDiv, Alexa.
>> JavaScript object with a hidden link.
>> Beautiful.
>> To that new unattached div node.
>> Beautiful.
>> All of the properties and getter setters that go with a div type.

>> Beautiful, there it is, including text content, and no need for a move here. Because we're not going to create this element unless the conditional evaluates to false and posts as not will. If it is will, and we could've done this the other way around, to be honest, couldn't we?

Like if post is not will we have createElement, but whatever. And at that point we would then create instead of every string, and end up appending nothing, no div element, to the page. We've switched our mindset from based on assuming that we are gonna always have a div and an input from HTML.

We then have to remove it based on the data in JavaScript too. Only creating elements, only determine what the user sees, based on specified, explicitly defined data in JavaScript. That is our source of truth. You want to do it, Mark?
>> When replace children executes every 15 milliseconds, will the new input element lose focus-?

>> Great question. Absolutely, and that is a line of code that I don't include here, but to even experiment with this you have to do so. We'll come to it in a second.
>> It is in the challenges.
>> It's in the challenges, exactly. So, great, so we will be going to challenges, the really lovely set of challenges built by Alexa and co.

Of these, actually let's shout them out, specifically Amelia and Jonathan and Alexa built out an amazing set of challenges. That we can push ourselves on all this content and extend beyond. We're gonna build out a visual virtual DOM, but we're not gonna implement multi-level nodes within it. We will within the challenges.

To actually do this in practice, there's only one line to change, which we're gonna see is. If we're recreating our input element on the DOM, every single time the user, well, every 15 milliseconds, it's a brand new element. We default to not being focused. Focus means the cursor of the user is in that input field when it is added to the page, when the page loads, when it's displayed.

We default to it not being focused, we will need to call the focus method Which would be something here like JS input.focus, and then execute it. That will insert the user's cursor in that brand new every 15 millisecond created input field. We're gonna need to optimize for this design, do not worry.

However, I don't put it on here because. So I can have our great friend online remind us. I don't put it on here because in hard parts, same support a second ago. And there's gonna be a few things like this where, if it doesn't break. I mean, this case actually it would break, it wouldn't work, we'd be sort of trying to click inside the cell, inside the input field.

It would just be bouncing us out every 15 milliseconds. But other than that one, if it doesn't break. Like to some extent my job in hard parts is to remove anything that is extraneous, extraneous, extraneous, there you go, extraneous. Remove anything that is extraneous in order to only keep the pieces that give us the ability to build out the mental model.

But like the diagramming is tedious. It means you're never gonna forget this mental model, flip an egg, and it's the only mental model. However, it is demanding, and so every chance I hand to remove a conditional, remove a line, albeit the focus line is really important. So shout out to our person reminding us, if I had forgotten to say that, that would have been bad.

But the focus line is the one where this wouldn't function without it. We're gonna see a few other things like that, where technically we're gonna apply a call to text content getter or setter. And we're gonna see later on an element that doesn't have a meaningful text content get a setter.

But we'll do it anyway in order to not write the conditional to say if there is not a meaningful use of text content in this case, do not call it. Because that's an extra line of code for diagramming, as long as it doesn't literally break with the exception of this focus one, it won't.

Then, for diagramming purposes, minimize minimize code. But know that there'll be a few places like that where we'll be like, this works, the user's experience it is correct. But would you actually do that or would you not? You wouldn't change the code you wrote besides add conditionals, we'll see, saying, don't try and call that get a set of property on that element.

Because it doesn't have that get a set of property, JavaScript were an error on it, so we're fine. But we do it for the purposes of minimizing complexity on already diagrams that, yes. Anyway, all right, so where were we? We were about to add our content. So now we're back to normal.

But the only difference is we created elements as opposed to use the implication that they were always on from HTML. HTML is switch them on, they're always there, true by default. We need to recognize they're not true by default. They are visual things a user can change, they are content.

Therefore, give them associated data. POST is our associated data for them. I know it's not like, doesn't look like we're saying jsDiv appears true or false. But we are having jsDiv's appearance where it does depend on post, if the user writes will, determined by data at any given time.

It will never display, except in response to except caused by underlying data tracked in jobs. Have I said that enough times now? I mean, again, it's like on repeat. All right, so let's go to line 8. Alexa, if you don't mind keeping us going here, and we'll keep this fairly simple now, keep this fairly short, this bit.

>> Yes, we're gonna use the value setter property on our JS input object to find the linked input note on the DOM. And set the value to the value of our POST variable, which is an empty string.
>> Great, and we'll do the same for.
>> The text content on the div.

>> Yeah, text is gonna be an empty string and then our value is also an empty string. So Js Div text content, what's our next line saying to do, Alexa?
>> Then we're going to set the on input callback function on our input to our handle input function

>> On input. If you can verbalize that as much as possible, I don't even know what it would be. Just so that as I write this there is some lovely background noise. [LAUGH] All right, input is gonna have exactly as you said, the callback handle input function as a handler, yeah, input handler.

Input handler was what Alexa rightly said, input handler will be set to be a reference to that handle input, brilliant, there it is. Come on, called the people's, anyone's fantastic and technical communication's anything but exceptional background noise. I apologize for my anything but endorsement of the wonderful technical communication everyone.

And then, in line 12, now, Alexa, what is happening here? Sorry, go ahead, please.
>> Now we are going to find our document object in our JavaScript memory.
>> Right.
>> And then find the body property/getter setter.
>> Right.
>> On that object, and then invoke the replace children method there.

And we're gonna pass in jsInput and jsDiv.
>> These two, exactly, jsInput and jsDiv, jsInput and jsDiv. And the way these are working is the body has a link to the body element on the DOM. jsInput, it has a link to the body element on the DOM. jsDiv has a link to the body element on the DOM.

There it is. And so, replace children. Well, right now body doesn't have any. You can see the end of the object is there. It doesn't have any, nothing's on the page inside a body. We're going to replace its children, strange old phrasing in the good old DOM API.

With jsInputs linked input DOM element in C, but with jsDiv linked in div Element in the C++ list, and we're going to set them as the children. I'm just gonna show the little arrows there, which means, Alexa, what's gonna show up on our actual webpage?
>> Our input and our div.

>> Beautiful, fantastic, and there it is. Automatically, because of our layout and render engines, amazing. We have displayed everything through one function, no mysteries, and all conditional on our underlying state.

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