The Hard Parts of UI Development

Understanding the handleInput 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 "Understanding the handleInput 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 diagrams how memory is allocated for the handleInput function. Since the function is a callback and not immediately invoked, the function's implementation is stored as an object in C++ and will be called once the corresponding user event is triggered.


Transcript from the "Understanding the handleInput Function" Lesson

>> Let's get started, I'm gonna go person by person. Paul, gosh, here we go, Paul, you're up for the challenge. Here we go, Paul, line 1 in our JavaScript code. We've already filled in our document object, it's there, it's gonna give us access to this C++ DOM. Line 1, we are trying to build out, remind ourselves, people, here a full user interface.

The ability to display content for the user, and for the user to change that content. Should be trivial. Turns out in the web browser it's four different APIs, it's five different run times, no, not five obviously. Paul, go ahead, what's our piece of data that hopefully we're gonna end up displaying?

>> Defining a variable.
>> Yep, perfect.
>> And it is an empty string.
>> Yep, and what's the identifier of the variable, what's its label? Post, perfect, posh word for label, people, if you want is identifier. There it is, post is an empty string. Next line, left-hand side, Paul.

>> We are, again-
>> Yep.
>> Creating a variable called jsInput.
>> Perfect, I tend to believe in const, variable being I guess a generic name for a label. But it's a label here where what's assigned to it will be constantly assigned, we'll not be changing what's assigned there.

I mean, we can change out its values if it's an object, but we will be linked to this object permanently. So a const, jsInput, and wow, okay. Right-hand side here, can you talk me through what happens, Paul, on the right-hand side here?
>> I'm not gonna do as well as it was done before.

>> Do not worry.
>> Okay, so it's going out to the document, it's running the querySelector function.
>> Right, so yeah, go ahead, keep going.
>> Which is going to look into the CSS DOM.
>> So into the C++ DOM.
>> It's C++, sorry.
>> Yeah, yeah, don't worry.

>> C++ DOM for an element of type input.
>> Beautiful, does it find it?
>> Yes.
>> It does, can it bring that whole C++ object back?
>> No.
>> No, so instead, querySelect, so let's write it out here. So we get, one, we are going to look at the link to in document, which is a link to the entire list of elements.

So link to the entire list of elements of DOM. Two, we're going to query, we're going to search for a given selector label by which we can select something, which is input. And three, and we find it. And three, because we cannot pull that object back in, and by the way, it looks something like type input.

Cuz we can't pull that object back in, instead in JavaScript we're going to produce, I guess, a corresponding object. It's not the worst way to refer to it, and it's gonna have [INAUDIBLE] stored into jsInput rather than do it here again. It's gonna have a link, I'm gonna keep it smaller this time, a corresponding object with a link to the underlying input element, and functions that are going to allow us to edit that input element.

You can always think of this as its own execution context. We then, out of that get that object and assign it to the global const. Paul, what's our global constant it's assigned to?
>> jsInput.
>> jsInput, spot-on, fantastic. And it has a hidden link to that input, there it is.

Beautiful, looking nice now, yeah, that's looking really nice, excellent. And that has on it automatically a bunch of useful methods. There's a lot. Which ones, Phil, can we see here that we're actually gonna use in this particular code?
>> oninput?
>> oninput, is there another one there as well?

I call them methods, I guess they're really properties, sorry.
>> Text content?
>> Text content, that's gonna be on our next one. Can you see on line 5 there what's-
>> We've got value.
>> Value, perfect. So we've got value, and these are both going to give us, when run, access to go and set, or get from a C++ object.

That's awesome, I gotta say I give credit to JavaScript for giving me this fine-grained control. Let's do another one without me going out of shot. So, well done, Paul. Too, Ian's already done an amazing job. So, John, you're up. Left-hand side of our declaration there, no declaration, our assignment there, sorry, is declaring what constant?

>> jsDiv?
>> jsDiv, and what are we gonna assign it, John?
>> That we are calling document querySelect.
>> Yes.
>> Document querySelector method.
>> Yes.
>> Passing the div argument.
>> Well put, yes, perfect.
>> And then that first ghosted slink DOM.
>> Perfect, yes.
>> And then finds the Div [CROSSTALK]

>> Does it find it?
>> Yeah.
>> You bet it does. And it's querying for Div, it does find it, we can't pull that C++ object back in.
>> Yeah, so it is creating a JavaScript object and represents it.
>> Beautiful, that represents it exactly. And it's specifically got a hidden link to it, and a bunch of useful functions to edit it.

Perfect, and then that gets assigned to what global const, John?
>> [INAUDIBLE] is jsDiv.
>> jsDiv, sweet, excellent from John, exactly right. And there it is, our object, and it's got a link hidden to. By the way, technically the way that link is specified in the JavaScript spec, which is the rules of JavaScript, it will say host defined.

The host is where is JavaScript running, which in this case is the web browser. As a host defined means do not, JavaScript, expect us to, sorry. Do not anyone else expect us, JavaScript, to define where a memory that will be. Have the host, which is the browser, give us just a position in memory, and that's all we're gonna have.

So that's what happens, we have a position in memory which is the Div element. There it is, beautiful, perfect. And then we also get added to this jsDiv as specified by the DOM API, written up by WebIDL. I mean some of these things, it's more just like it's nice.

The model's more important than the names, but it is nice to have those names because we do wanna be able to go and use them. And annoy engineers by saying things that they, no, no, we wanna be inclusive, we wanna make sure that all, all the people interviewing you are feeling comfortable, but a little bit intimidated so that they.

Who wouldn't want to have your interviewer a little bit intimidated, in a good way, in a polite way. There it is, text content, I guess I shouldn't suggest it's a function, but it is acting like a function. It's a property, but it's, yeah. Okay, perfect, we now have two, we heard representations of DOM elements in C++, I would call them corresponding objects, I would call them access to objects.

Okay, all of them are just made up terms, by the way, don't expect to find those in. Okay, now what are we defining here?
>> Line 4?
>> Yes, perfect.
>> So we're using the function keyword to say hey, runtime, assign in memory, make some space for something called handle input.

>> Perfect, and assign all of its code.
>> And yeah, it's an object.
>> Function definition, yeah. [INAUDIBLE] object under the hood, but or is it the fanciest definition of function ever? So well don, Wyatt. We're defining a function and handleInput, we've got a really good description of how it's doing it in memory, that's really cool.

>> Sorry. [LAUGH]
>> No, no, it's really good, it's important. It's saying free up some space in memory to save the text of this function, absolutely. And/or a parameter list, a list of potential inputs. Well, there's none, so yeah, but it would if there were, yeah, perfect. Now, because the reason I say it's so valuable is the next line is a tricky line.

The next one is a tricky line, so let me give a verbalization first, or well, let's say the goal. Our goal is we have written a function handleInput, we do not go inside it right now, we just grabbed all of its code. Remember that, people, no going inside of function definitions until they're executed invoked code.

We just grab all of its code, we've saved it into JavaScript memory. What we wanted to do, taking a look at it, it's going to update JavaScript data post with the value. Potentially I have a feeling, from running the value getter, in this case it's gonna behave as a getter, to figure out whatever the user wrote here.

And it's appeared on the DOM element that is linked to by jsInput, so that input DOM element. We're gonna grab that, pull it back into JavaScript, and we're then going to use that line 6 to update jsDiv's text content. That wasn't good verbalization, right? To use the setter method property on jsDiv to update the Div's text in C++ on the DOM.

We don't know when the user is going to start writing something in the input field. And this is where we want to, instead of trying to execute handleInput right now, save it. Ideally, I guess, a link to it from the input element on the DOM, that can then enable it to be passed back, called back into JavaScript.

If you've watched hard parts, callbacks and higher order functions, I always thought it was weird they were called callbacks. Because they were never called back, they were executed right there and then inside a map. When you pass a function to map to execute, it's executing right there and then inside the higher order function.

A callback to me is something where it's like we've saved a reference to it, and at a given moment, maybe when a user starts writing, it's called back into JavaScript to be called in JavaScript. And that is what we hope will happen here. Our goal is that this function's code, that Wyatt so perfectly described being saved, will be somehow set to, set's not a bad word for it here.

Set to this input DOM element's handler, to handle the user inputting on this DOM element. Remember these two are completely bound together. Any code written here if the user types anything, the DOM element will know. And to have that set as its handler that will then run JavaScript code back here, or call that function definition back into JavaScript.

Such that it can execute, such that it can run, that we could then go grab the data that's on the DOM at that point from the user typing, right? Two things are happening, that the user is typing, it's triggering a function to call back into JavaScript, and it's putting data in the value property here.

Pull that back into JavaScript where you can then go, yeah, pull that data back in, assign it to post, and then use that updated value of post to update our Div. If only we could do it right there and then, okay? [LAUGH] Instead, we're gonna put that data in there, into that input.

The user is gonna type into the input field, and [SOUND] we're gonna have to bounce back and forwards. But we have to, right, because it has to be data that can be changed. Remember, seeing seven on the screen is pixels, it's gotta be changed to eight. That means there's gotta be underlying corresponding data, fine, the DOM has that, not enough, that we can change.

Only JavaScript has that. Meaning any change we wanna have happen, which is vital for the user experience, anything, otherwise there's no change, it has to happen in JavaScript. Okay, so let's do that. Great job, let's assign that function in line 8. Give it a go, Alexa, if you don't mind.

>> Okay, so we are gonna find our jsInput object in our JavaScript memory.
>> Yeah, keep going.
>> [LAUGH] And we are going to set, well, we're gonna find our jsInput object and use our link to that DOM element.
>> Perfect, we find our jsInput object. Look at that, perfect timing.

Find our jsInput object, there it is with its link to the corresponding DOM element input, and?
>> And then use oninput as a setter to set the handler for input-
>> Exactly, set the handler for handling input, exactly-
>> To be our handleInput function definition in JavaScript.
>> Yeah, beautiful, and technically it'll be a reference.

Cuz just like we can't pull a C++ object into JavaScript, vice versa, we can't attach a JavaScript function in C++. Instead, it's a link to this function back here. But for our purposes, just visually, we'll show it right there, beautiful, fantastic. So we used our setter. I wanna hear clarifications on this, people.

Please don't assume that others are getting this. I wanna have someone verbalize this for me in a second, this is a really hard line. So jsInput is the link to our object in JavaScript that we created earlier by querying for the input element on the DOM. We got an auto created object with a hidden link to that DOM element, we're now using that fact to run its oninput setter method.

This setter property was added automatically with the help of querySelector because it knew we've got a link to an input element. So it adds all the appropriate functions. It's good, it's good, I'll give it that. We're gonna use that setter to, well, one, we're gonna check what the linked element is, it's input, so check that it's input.

And then we're going to, two, set the handler for handling user's input. As far as the bad names in programming go, and there's a lot of them, handling input being called a handler? Handling the user's input, it's got to be one of the best names, I would call it that.

That suggests I think I come up with great names, I don't. Okay, and we're gonna set its handler to be the handleInput function code. Beautiful, and that's it. We now have a full, I'd actually argue we now have a full user interface, we've set it all up, right?

We have content, we have displayed, I guess, structure boxes for stuff to be. We have a place for a user to write something that they are then going to be able to trigger that affecting the underlying data. And that affecting the underlying data in line 5, we're gonna grab whatever the value is that they typed in and store it in post.

Will then be used to affect what they see by changing Div's content on the page. We've now set up, time's gonna pass. And what's funny about this now, and this is the nature of user interface, is this system is now gonna get hit from outside of it, okay?

And that is gonna be the user writing something. So we don't have code for the user writing, so our execution of JavaScript is actually finished. JavaScript will continue to run because there are functions that have been set to listen, and it keeps track that there have been functions set to handle a user action.

So it won't actually execute JavaScript, however, we're done with our synchronous code that we wrote. We're gonna now have the user take action from outside of this system, and that's gonna then affect the flow of user data into JavaScript and back out onto the screen.

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