The Hard Parts of UI Development

Auto-Updating Views UI

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 "Auto-Updating Views UI" 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 begins diagramming the UI elements and underlying data structures for the next code example. An input element will receive input from the user. The event handler will update the JavaScript data.


Transcript from the "Auto-Updating Views UI" Lesson

>> We are returning to our full UI without auto updating views from our data. Here is our code, we've removed one of our handlers, so it's a slightly simpler implementation here, a slightly simpler implementation here. We are now just enabling the user to type into the input field and then for the preview of that to show up in the associated div.

Okay, let's do it, I think it is got ourselves back into being familiar with it. Note here the only changes we've made. So we are going to set up post data or put up post data in JavaScript memory. We're then going to head to our JavaScript, no, see, I really need to.

[LAUGH] We're gonna head to our dormancy plus plus to grab our input and div, we can't grab them and pull them into JavaScript, just links to them. We're then going to save our all important function that converts our data into our view under all circumstances. No manually changing our view anywhere else anymore now, just through this function.

Then we're gonna save our handler that's gonna handle the user taking an action. That's the outside influence of this system that makes this system so interesting and hard to reason about, of course. You can't see user action in code, there's no line of code that says user takes action, that happens outside of the system and influences it.

Then in that handler, we're also going to, if the user has, my goodness, God forbid, that's a very old-fashioned phrase, written will, then we are going to remove the div entirely because they need to learn. That is not, anyway. All right, we're gonna attach that to the, I probably should have changed it to something else, shouldn't I, just rather my name.

But all right, then we're going to have that data view function be running on repeat when the user changes the data. Via the handleInput function running, the view will change based on that data. But just notice, I have a feeling, well, I mean, we can see, we're affecting what the user sees in a place other than the dataToView function.

But we already were, it was in the HTML code that we already were affecting that view. So I mean, look, as long as there's gonna be some view that if it can't be changed, I guess it doesn't matter per se. But as long as it's possible to change it, there needs to be data behind it in our new one simple rule, there must be corresponding data associated with anything that can change in the user's eyes.

I guess if the input and div couldn't change, maybe it doesn't matter, the only thing to change, the content, maybe. As long as it's possible for us to remove and we are in this case, now I'm worried that there is not associated data determining whether or not, in any given situation, that div is there or not.

Instead, it's only in the situation where the user is inputted do we determine whether the div is there or not, it's not otherwise. Okay, so let's get started, people. We're back, we're back, we're back, we're back, we're back. And so we are going to start, what do we have?

We had our view, I guess, our web page that was displayed and rendered.
>> I think it's too big.
>> [LAUGH]
>> It is too wide, isn't it?
>> Yeah.
>> Well, it's too late now.
>> [LAUGH]
>> All right, and then we're going to have our C++ model of, let's get this one warmed up, model of that page elements that is just essentially a list.

Now, that is too small. That is essentially just a list of elements that we get to add to. Technically is an object, the O stands for object, but it's an ordered list of elements. So we can think of it as being on ordered list of nested elements. So we can think about it as being a list for our purposes, it's just for simplicity's sake.

Then we have a wall that divides our JavaScript runtime from our C++ runtime. Note, anything on this list is added directly through the layout and render engines to the page. We get to add to an ordered list in C++ of objects, technically an object of objects, via some text in an HTML file that we can load in with file open.

How often do you get to add things to a C++ list? Order list of objects by file open and listing the things you want to add? That's pretty powerful, that's our HTML for you. Super, super crucial language, definitely something that we all value. Because it is the most intuitive thought free design language out there, something we all value in a very serious way.

So, we do. So let's go and add some elements to our C++ list in the DOM, which is just the posh word for this list of elements. Let's do the HTML, starting with justice. Let's add our three elements to our C++ list via our HTML code, which loads in, sorry.

>> I've got an input.
>> Yeah, okay, great. Yeah, you're fantastic, I'm just gonna remember I need to show it loading into our schema. There it is, the HTML parser. Into that goes the HTML file that gets to add things through the Web IDL. So Web IDL also is the description of the DOM API.

Remember, remind that just so for clarity again, the DOM API is the borderline English language description of how we can access this C++ list. It is written out in its formalized structure through the interface description language for all web browser features, known as Web IDL. And that is actually what allows the past HTML code to be added to the C++ Dom list, which is then produces actual pixels on the page.

Justice, please go ahead.
>> Yeah, we've got an input.
>> Perfect, input, there it is. Next.
>> Div.
>> Okay, see, I've got to get myself back into it, I'm gonna put it right to the left here so we have lots of space. Input, there it is, div, and last?

>> A script.
>> There it is, input, div, script, beautiful. They go to walk Justice on our page.
>> We see an input, a box.
>> Beautiful.
>> And then there's a div, that's really not shown but is there.
>> Spot on, thanks, Justice. Okay, now we go into, yeah, go, Mark.

>> Is it deliberate that in the code dataToView doesn't check if the jsDiv has been detached by handleInput?
>> Yeah, yeah, yeah, this is by design some code that we'll at least have to do some reasoning about, let's say, yeah, absolutely. [LAUGH] No, this is the sort of thing that we'll want to be having to figure out.

>> We're on a journey.
>> We're on a journey, yes, exactly, we're on a journey here. All right, we're now loading JavaScript. All right, no time for jokes, now we're loading JavaScript as soon as we hit that script tag which created a script node on our C++ list of elements.

And that's gonna switch on JavaScript. Here it is, JavaScript has a memory, it has a thread, which is the posh word for process ability for the computer to run code line by line of execution of running code. It also has in its memory a bunch of useful objects that are full of functions, or get a set of properties that are actually accessing features outside, like the DOM.

So let's load up JavaScript, here is its memory, which is its store of data, or that sounds good. That's literally getting the sizes wrong of every single one of these cuz we got no space to be wasting. So that's a store of data, which is fantastic, because we said that for any user interface, we are, one?

>> Displaying content.
>> And two, letting the user?
>> Change it.
>> Yeah, well done, everyone, especially-
>> [LAUGH]
>> I think it was everyone say roughly the same thing.
>> [LAUGH]
>> Okay, and so we need data corresponding to something that they can see that can be changed.

Otherwise I can't change pixels without corresponding underlying data. Even if that data is just true or false, even if that data is just show or not, it's still data. It's still not just pixels, which are the manifestation of some sort of state or data. Okay, there we go, I'm gonna start, yeah, showing that JavaScript runtime here.

So we have immediately in it an object by the name of document. Alexa, help me out with what's in that document object. We have a hidden property, that is a link to let us access the DOM. Beautiful, there it is, a link to let us access the DOM.

The DOM, let's call it what it is, the DOM, exactly. Perfect, and then we have a bunch of what on it?
>> Properties, which are probably methods.
>> And also some actual methods, but it will not like querySelector that lets us do what?
>> Interact with the DOM.

>> Yeah, beautiful, there it is. Perfect, and now we get into saving our data, and we're gonna pick up the pace here. Well, actually, Alexa, what are we doing in line one of our JavaScript here?
>> We're declaring our post variable and initializing it to an empty string.

>> Beautiful, keep me going, feel free to sort of, I mean, to be fair, actually, we're getting back up to pace. So we'll do it steadily, [LAUGH] don't need to. So we declare what, Alexa?
>> Then we're declaring our jsInput variable. We're assigning it to the result of invoking querySelector on our document object with the string input.

>> Brilliant, querySelector with the input, with the argument, this string of input. And that is going to, let's just do it again just to remind ourselves or give me people. What's its first thing that it's gonna do, Alexa, in order, yeah, go ahead.
>> It's gonna use that hidden link on the document object to-

>> Head to-
>> Yes,-
>> To the DOM.
>> To interact with the DOM. Where it's going to search or query for what selector?
>> Input.
>> Brilliant, a selector is just any label, actually, it includes class names or IDs or other ways in which we can select, grab an element.

And here we are grabbing which element?
>> Input. Input, we can't retrieve it back into JavaScript to make changes to it because it's a C++ object, object, object in C++ runtime, the DOM, the model, the list of elements on the page. So instead, JavaScript gives us what?
>> An object.

>> Well, yeah, a regular JavaScript object with its own hidden property linking to?
>> The input node.
>> Into the input node, brilliant. And also some useful functions that will be applicable to editing, accessing, deleting, removing, updating, moving an input node, including what?
>> Value.
>> Value, and I think we've got oninput as well.

>> Yes.
>> Brilliant, and that then is stored. It's nice to go back over this people, right? Seems already hopefully relatively familiar how this is, and I'm sure you realize become our standard model here, people. So that's what's happened inside querySelector, and the output of it is stored into where, Alexa?

>> jsInput.
>> jsInput, fabulous, and there it is. And hopefully, we should be able to do that somewhat by analogy for the next one. Do you wanna keep me going?
>> Yes, after jsInput, we're gonna declare a variable jsDiv, and we're basically gonna do the same thing, except we are gonna query the DOM for our div this time.

>> Beautiful.
>> And the result that is stored under jsDiv is gonna be a JavaScript object with a hidden link to the div.
>> Beautiful.
>> And all of those automatic getter-setter properties that let us specifically interact with a div.
>> Fantastic, they're pertinent to the div elements on the DOM, which include here.

Which one are we using?
>> Text content.
>> Okay, fabulous, there it is.
>> And remove.
>> And remove, perfect. Thank you. Okay, no, we'll add it in here and remove. That's a crucial one, isn't it? That's exactly what gonna use. Brilliant, let's give a hand to Alexa.

[APPLAUSE] Here's really good stuff from Alexa. All right, let's move on to why, what are we doing? We've now got our two accesses, which is great because we now have in JavaScript, I guess, the ability to access and change the pertinent, the relevant for our user interface, DOM elements, and therefore, view, what the user sees, what the user views.

So why, what are we doing now? We've saving two crucial functions here, one that's gonna pipe data through to the view, the other there's gonna pipe action back to the JavaScript environment from the user, okay.
>> Yeah, so we're assigning two functions to memory to call at arbitrary times later.

Do you want me to go into the actual-
>> Definition of them?
>> Well, I know you don't want that, the steps inside.
>> Yeah, as long as we're not calling, we wouldn't even touch the code inside, so we don't even describe them. I think for our mental model, it's always best even when we define a function.

Of course, when we actually do write the code, we look at it and we think what it's going to do. I think it's always best for our mental model to not even think about the code inside. JavaScript isn't, it's just saving it. And so what's the next one we save?

>> Then it's saving a future input handler named handleInput.
>> handleInput, I wish I had better names for those that were not, but yeah, okay, beautiful. And then I tell you, I think a really challenging line, line 15, because it pushes on the, if you wanna see a function, it's nice to see the keyword function.

If you wanna see a function run, is nice to see params. And yet on this line, in line 15, we are using oninput as a setter, which is acting as essentially a method that is code running to assign on the right-hand side a function that is not gonna execute but is being referenced.

But later on, we'll execute at point of user action from the user over here on the web page. So that line is, I think it's a tricky line, a lot of things that don't look like what it's doing. Okay, so let's go through it, though. So take it away why if you can.

>> So the function handleInput that was defined inside the JS runtime-
>> Yeah.
>> Is getting passed to the oninput method of the jsInput object and the hood would that oninput.
>> Yes, all right, gotcha, tes, exactly, I'll write this up. So it's going to, go look at the link to which element in the DOM?

>> The input.
>> Input, perfect, there it is, which would have a value property and handlers including four input. We'll just do input from the user. And perfect, we are setting its input handler to?
>> To handleInput.
>> Yeah, exactly, I'm sorry, the terms are a bit. Yeah, so it's gonna set its input handler.

None of this is happening in JavaScript, this is just a setter-getter that's going to pass this out. As we saw text content being assigned, we wouldn't want our hi or our post to be assigned here. We want to use this to set it out here, but we do need to know these are different runtimes, otherwise, they will behave in ways other than we'd expect.

And so into the DOM, we send our handleInput function. And by the way, these terms, I say handler's input, they actually won't have exactly these names in this instance or instantiation of the C++ class for an input element. But we don't need to worry because we access them from the JavaScript API definition, or the JavaScript implementation of the DOM API's definition, which says oninput will do the job and attach it as a handler.

What actually the C++ implementation looks like will be specific to the given DOM implementation, and it doesn't really matter for us. But roughly, it's handlers and these are input one to which we are gonna attach handleInput. There it is, and I'm just gonna separate these so we cannot get too confused about each element.

Great, good stuff, now did I miss anything? Yes, I did, [LAUGH] okay, I've got more here, one more line to do, good. Now, let's add our call stack here, because I think we're about to start having some specific things to think about in terms of the ordering and execution of code.

The ordering and the running, and then our callback queue. There it is, and we know that there's also this event loop that is checking whether there's anything on the call stack. And that all global code has finished running before anything in the queue of functions that have been called back Into JavaScript to run are added to the call stack.

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