Check out a free preview of the full The Hard Parts of UI Development course:
The "UI Component 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 completes the UI Component example by walking through the effects of user interaction. The setInterval function calls dataToView repeatedly. As a user interacts with the input element, both the input and DIV elements are updated.

Get Unlimited Access Now

Transcript from the "UI Component Interaction" Lesson

>> All right, we have our content displayed. Now it's time for user action. It's not a closed system, it's a system where users can come in and cause events to happen in response to their action. What is the use of action here? We're gonna keep it pretty simple, and it's a user's gonna type.

[00:00:15] I think they're gonna have to type will unfortunately, type will, and there it is, will shows, it's extraordinary, it's so happy to paint my fingers but not the whiteboard. There it is, and Will will go into the value automatically. I think our friend online was almost implying that.

[00:00:43] Like, hold on, it's already automatically there, fantastic. Thank goodness it is. So, 2 is an event saying please go and execute handle input. And that's what we go and do, we go and execute handle input. Data to view is off the call stack. So, call stack is gonna have executed on it.

[00:01:01] Well, actually, Matric, can you tell me what's gonna happen from our handleInput function is gonna be added to what and what and executed how? Tell me what's gonna happen.
>> Is it assigned to callback queue first, right?
>> Yes.
>> And then the message loop is gonna put it to call stack.

>> Yes, perfect. And that's where now handle input will be executed. We don't add porins, instead, we rely on JavaScript doing so. There it is and it gets to create a brand new what Metric?
>> Would be assigned to the point.
>> We're gonna execute.
>> It's gonna execute handle input, right?

>> Execute handle input, create a new, everyone together. Execution context, fantastic, exactly. We've got some code to run.
>> [LAUGH]
>> It's got some code to run. So we're gonna create a new execution context for it. And there it is, running handle input. It's a very small one though, because all it's gonna do is change data, that's the only thing we can do is change data.

[00:02:06] And the data we're gonna change is the value of post, which we're going to assign to the result of getting the value that was just inserted by the user, the string will, and then assigning that to post, beautiful, there it is. As a JavaScript string, the string Will.

[00:02:29] Forgive me for using my name, but I hope it's not so bad. We'll be using that to then remove, or not remove, but implicitly, we're not gonna display some of the results. So it's hopefully not something to self-congratulatory, it's rather the opposite. So there it is, data change done, and how nice that we know our data changes happening in one handler function, beautiful.

[00:02:52] Not lots of different things up displaying content just changing data. It's not a truth, it's a move, is an effort, it's at a tactic to make our lives easier to reason about this complex state, and view relationship. And so now, we move to queue, we move to automatically.

[00:03:14] Well, this is off the call stack. And we know that what's gonna happen is our data to view function is going to execute because it does love to execute every bloody, sorry, I didn't just swear. Sorry, every few moments, every 15 milliseconds, do I add the parens, Phil?

>> Not yourself.
>> No, exactly, JavaScript's gonna add data to view to the call stack. I'm just gonna do D to V. So the call stack, there it is. It creates everyone together a brand new.
>> Execution context.
>> Beautiful, and so we're now gonna convert our data to our view based on this new data.

[00:03:55] And this data is not just gonna change the contents of our boxes, it's actually gonna switch out one of those boxes. It's gonna not even create it. Okay, let's do it, let's dive into it. Alexa, if you don't mind doing it again, now that new setup, our new state, what are we creating?

[00:04:13] And we are gonna create these from scratch are, aren't we? Yes, so tell me what's gonna be reassigned to JS input?
>> Yes, we're gonna create a brand new.
>> Yeah.
>> JavaScript object with create element.
>> Let's do the first one, exactly. Just input is gonna be reassigned to a brand new created.

[00:04:31] Talk over me, like so if you don't mind
>> Yeah, so we're gonna use that create element method on the document object to create a new unattached input.
>> Perfect, brilliant. Brilliant, everyone get that what Alexa said they're a new unattached input element.
>> It's just floating around in there.

>> Okay, yeah, exactly, there it is. Look at that lovely pen. Very happy and, that was a Bob Ross reference, wasn't it? Very happy pen here, and?
>> So we're reassigning JS input, we're gonna get that new JavaScript object that has all the same, getter setters on it but our hidden link because we are reassigning it.

>> Do we remove this one, I think just for the first one we're going to, so we truly know that it's lost its JavaScript label, this input element here, because we are reassigning to a brand new object as the output of this create element call. Not the document I never fall for the trap of document.createelement is going to return out to an object, as you said rightly, Alexa.

[00:05:51] So there we go. I hope the camera pans down to my pen experts who needs to be acknowledged for the hard work that they're doing. So that is a brand new object linking to as you rightly said, Alexa, a brand new C++ instance of the input class in C++ an object and it's a link to it.

[00:06:13] There it is, and it has all of the relevant functions. It looks exactly the same as before, but it is a new one attached to, dear. That's I don't even know that is. It is a new one attached to, it was actually wrong it's on input isn't it, it's a new one that's attached to our underlying input object.

[00:06:34] There it is, okay, and then the same for jazz div, we declare but not, what am I talking about? So you never take it for granted? What is gonna happen here? Why will you tell me what's gonna be assigned here to JS div?
>> Yeah, so online five first we're gonna execute the ternary statement.

>> Beautiful.
>> We're gonna check the value of post which currently is Will.
>> It is well, is it true? Yes, it is. So what do we assign to jazz div?
>> As a result we're not creating accessor objects we're not creating a new node we're creating an empty or reassigning JS div to an empty string.

>> Fantastic. Okay, then we're gonna add a handler. It's the same handler but function but we're re adding it here as our handler with handle input being attached to the input handler property, and this is what we've just done there in line ten, I guess. Use the oninput setter on the jsinput newly linked accessor object to the new input DOM element to which we attach a handle input.

[00:07:50] Function as its input handler. By the way, we can call that function anything. We can call it y, as long as it's the function that then gets assigned to the input handler using the input setter, beautiful. And now, we're going to go ahead and, we're gonna go ahead and run in line 12, what?

[00:08:16] Let's have y again.
>> Yeah, we're going to look up. We're going to call the replace method on the body object which is itself a property of the.
>> Right, let me just write this out, forgive me, one second. So, we're going to say, sorry again, say it was perfect what you were saying, I just wasn't listening, I was thinking about my pens.

>> [LAUGH]
>> Very fair. We're going to call the replace children method on the body object, which is itself a property of the document global object. Then it's slightly different this time.
>> Right.
>> Shall I go into that?
>> Yeah, go for it please.
>> Yeah, yeah.

>> Of the two arguments, the first, JS input, is very similar to the previous element.
>> Very similar.
>> Attaching it to the DOM. The second argument, however, JS div, is currently just an empty string.
>> Perfect, so that'll be essentially ignored. And we end up with, note by the way, here's another case where that JS div setting text content, I skipped over it knowing it won't break.

[00:09:24] Paul raised this earlier knowing it won't break, would I in practice actually determine that it's better to say, if Js div is not an element, then don't try and add content to it, but in this case it doesn't break. And my purpose is to try and keep things as minimal as possible.

[00:09:41] And so, yeah, same thing here. Our Js input, js div, js div and empty string acts as ignore this element, don't append it. And so why, what is the element that gets appended to our page?
>> Just the input element.
>> Just the new input element. And these two get unappended.

[00:10:03] And we get instead a link to our new input which we set the did I forget to set the value of it? After we checked the conditional I forgot to update my value of JS input. Let me do that, what was the value set, y2?
>> It was the string Will.

>> Yeah, thank you. And it's in white because it is coming from JavaScript data. And it's set, therefore, we are going to remove this element, and a whole brand new element is being appended with Will. And the user won't even notice a difference as long as we set for that element to be refocused on via the JSinput.focus method that ensures the user's cursor jumps straight into it.

[00:11:02] So that as they're writing, they're not like I wrote a letter. I mean, we didn't get to it's 550 milliseconds too fast, and it will bounce out if we didn't write anything. Now that's because in reality, we are rebuilding our entire model of the page here, based off our underlying data.

[00:11:19] And that is incredibly nice for us as developers to be able to say everything the user sees is gonna be defined in relationship to some underlying data. And we're not gonna say if the data changes this way, if there were already elements only remove them under this condition, nope.

[00:11:37] Everything will be one to one data generates the exact elements exactly as user sees them from that data. And then user action can only affect what you see via changing that data, so you wanna keep that function one to one it better handle the creation of elements on the very first time, and the later edit of them, not by changing or removing them, but just by saying, do it again, conditional on the underlying data.

[00:12:06] Problem with that, and we're already seeing a preview of it, is while it gives us a full picture of what is gonna be displayed, a list of elements in. Sorry while it gives us a full picture of what's gonna be displayed from our data in JavaScript, which we could even use to draw out in JavaScript, [COUGH] draw out in JavaScript elements before they appear on the DOM.

[00:12:28] The downside of it is, hold on, we are recreating elements on the DOM, we could have 1000 of them, are we really going to have that on every single time a minor detail and data changes? So, if we hadn't by the way, had Will here and we'd had let's say Wyat or John we said, or Alexa, or Phil or whatever then we would still have had our div created.

[00:12:56] JS div is going to be the result of first checking your posts as well. If it is, don't even create an element as we perfectly got here from why don't create an accessor instead, just create empty string. If we did get a post of, let's say, value John, then as Alexa was saying earlier, we would create an element unattached in the C++ list of elements.

[00:13:24] And we would then assign an object accessing it with a hidden property into JSdiv, into which we would then add the text, or with which we would then add the text to the DOM element, the text being, let's say, John. All right, everything you see is now dependent on underlying data and it is funneled through one function, what is that function known as?

[00:13:49] It's a component, it describes in full, only took us x number of hours. To get to a full UI component describing in full underlying data, and its appearance on the page under all conditions of what that underlying data could be, under all conditions of what their history of use interaction is.

[00:14:12] Because all user action ends up becoming state, therefore, a function that describes the translation of that state, that data to view is a full description of the entire piece of content. Its underlying data all possible conditions for what can be displayed are all captured by the description of the relationship between that state that data and what the user sees.

[00:14:39] Don't forget, it should also, and must and does, attach the handler, there could be many of them in practice, that then passes back the user's action as a submission to change that data. Where we have hopefully reasoned through and designed, based on that data, whatever it is, not what came before, but whatever that data is at that moment display our content of it.

[00:15:04] All right, let's have thumbs on this fully now all we've changed is add the creation of the elements as well into this data view function, partially known as a UI component. I wanna see your thumbs, you lost me. Paul played me there, pulling like this, like that, all right, very.

>> [LAUGH]
>> It's okay, I wanna see clarifications. Alexa has got a clarification, Ian's clear, Paul's clear, Wyatt's got a clarification, Alexa, take it away.
>> Small thing about replace children just to clarify my understanding because I have never used C++ and I don't know the details of how everything works in there.

[00:15:41] But when we do replace children and we like unattach the previous elements from the body or like remove the reference to it and because we no longer have a JavaScript like pointer to them, immediately garbage collected, we don't have a memory leak.
>> Yes, well, I mean, it's gonna depend on the engine design is gonna depend on the engine design, okay.

[00:16:09] So I often brought up this tool that I found, maybe people even used it, that Microsoft has that allows you to look for any memory leaks, that is elements on the DOM that do not have labels in JavaScript but are not, also not attached, meaning you can't use traversal like searching for selectors to even retrieve them.

[00:16:31] They are only gonna be retrievable by a label, but the label's gone, which would be a memory leak. That's elements that don't have any access anywhere in our runtime from JavaScript, any access by us as programmers ever again, and yet they're still left in C++, that would be a memory leak.

[00:16:49] There is a tool from Microsoft that can identify any of those that you might have missed. That makes me somewhat think there may be scenarios where they could still sneak through but I don't know, that could have just been the implementation for a given browser historically or something like that.

[00:17:01] Because in practice, once they're replaced here in a modern browser they will be cleaned up and removed. So maybe there's older browsers where that's not the case but in this they would be exactly as you say Alexa removed. Okay, folks, so we are now going to function that fully creates element and relate to data or view is known as a UI component.

[00:17:22] Given we said, I really do like that phrasing, there are two things we're doing with UI engineering. One, display content, well, we're not gonna miss a chance, are we? One,
>> Display content.
>> Two, let the user.
>> Change the content.
>> Yeah, change it, exactly, change the content, exactly, change it.

[00:17:37] Well, change it, change the content is wonderfully ambiguous. Record right to cuz in the real world they're the same thing, content is what I see and it's its state, its reality where it is it's changeable. State is the ability to then see that these pixels in the universe and move them here, not in the computer those are two separate things.

[00:17:54] However the more we can make them the same the better. Particularly difficult in JavaScript because data's in one and what you see is in another runtime C++. Function that fully creates elements and sets up that data to view relationship that sounds pretty useful. If we want data to view our content to be bound together it's called a UI component, combines everything into one function, creates elements, sets that data content, attaches handles, and displays, describes in full what the user will see.

[00:18:21] In how it relates to underlying data the view and the data I would call the content that's not to say like the content is the view of the data in a sense, ties Data View handles how user can change the underlying data and therefore what they see because it also reruns the update view with that new data.

[00:18:41] React, angular, views, felt, all built out UI components are such a core part. Because what's even more awesome is once you have one, you could have others. You could rerun this one if you gave this a name like create input. I don't know what you call it, create input preview, which is input preview.

[00:19:00] Then now, we'd even call it, not even create, because it's not quite saying create. It's a description of the full relationship between the data and the views. I don't wanna even call it input and preview. You may wanna split them out into two, but let's say we kept them as one, input preview.

[00:19:14] You could now run that 20 times and have 20 input previews. Ours wouldn't quite work cuz we'd globally saving them, in practice, we wouldn't globally save them. We'd keep them in here, that handler would have access to them because the handle be defined inside and get via closure, access to our credit elements.

[00:19:31] In order for us to keep our diagramming simple, we've stored them in global, but in practice, we would probably store them locally in this UI component. Encapsulating bundling up our full end-to-end data to view creation and the relationship between the data and the view, both from the user's action back to the data and from the data to what the user sees.