Check out a free preview of the full The Hard Parts of UI Development course

The "UI Component Setup" 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 the initial setup of the UI Component code example. Like the previous code versions, global variables are declared to store data in JavaScript memory. Since the dataToView function handles the creation of the elements, the only initial element stored in C++ is the body element.


Transcript from the "UI Component Setup" Lesson

>> We were just realizing that actually there are more things the user sees that can be changed than just the text content of our elements on the page. Actually, even the existence or not of the element, that is the div or the input is also something that is a result or should be a result of underlying data.

That we are therefore able to funnel pipe through our data to view converter function, such that the only place that can affect the view what the user sees of the content in the app is through the data to view converter, such that the handlers, that handle the user's action will only be able to affect that data.

And yet this handler we had it affect the view. Maybe we thought it was gonna be okay because it was a div but actually it turns out even the division, even though box on the page is something that we can change or is content that the user can change and therefore we should have it mirroring, matching, mapping from some underlying state or data in JavaScript such as we have a source of truth our JavaScript, state, or data.

And that led us to, add to our data view function, two new lines. Two important new lines here, our creation of our element, our div and our input, not just our filling out of its content and then line 8 and 9, but also our creation of our element in line 4 and 5.

And remove the creation of the element from our HTML code. So now our data to view function is also creating the part of our view, the buckets, the containers, the input and div, into which we're gonna put our text, our value, our text content setters, will do that.

All within data to view and all conditional on underlying state tracked in JavaScript that gives us a single source of truth, posh word for way of saying a single place in which the cause of what you see is determined. And that cause is our post data. Even if in line 4 we see our Jess input is gonna always display independent of whether post is, I don't know, an empty string or the text will or something else, fine.

It displays in all possible states of the value of post. That's okay. It is still dependent definitionally on post because it is being created through our data to view. And if we did wanna change when input shows up or not, we could easily do so in our data view piping function from our data to what the page displays.

So let's get going people. We're back into it, let's just flag where we're going, once we have, this is called a UI component. Funnels our data to our view the whole way through, and we are back. And we are hopefully going to be able to now walk through our models of our execution quite efficiently, so that we can start to get to our visual DOM.

Here we go, look at that. That's not too big a web page, is it?
>> [LAUGH]
>> Ian approves. Then we have a model of this page that we have the ability to interact with HTML or JavaScript, but we're really gonna lean into using JavaScript for it now cuz we want to have even the elements are in a sense, things that can be changed and therefore require underlying data, which does not exist within HTML.

Even the creation of a div and an input are things that you can switch on or off, which you can't do from HTML or one-time display. So now even the creation of elements we're gonna do from JavaScript, where we can have them depend on changeable data on state, okay?

So there it is our C++ list of elements that we access with JavaScript as our primary access point now. And then remember, we do still load initially our HTML file. There it is. My provenance diagram by the way prior to storing the file. Now, I've always been very proud of that.

Load that into the web browser into the HTML parser. My goodness, hopefully we have this model. And that's going to then add each of those elements to the list of elements in C++ The DOM. Okay, and then if we hit a JavaScript script at this point is all we're gonna hit in our HTML parser.

And nowadays, we load our JavaScript file switches on the JavaScript engine with its memory, and its accesses to things like the DOM. The output of the DOM via the layout and render engine is actually an image of the page 60 times a second, literally bitmap graphic that's passed out to wherever it's gonna be displayed by the graphics hardware.

The graphics hardware being the graphics card, or graphics processor, and that is our schematic. But we do need to add something to our list of elements as our HTML nodes in. And it's going to be, That's gonna be what? Phil, if you just help me out quickly here with our first element on the DOM.

Now I think the only thing we're loading in.
>> It's gonna be our script elements
>> Yeah, brilliant. Let's then also now have our body always on here as well because we're always going to, actually, we don't need to show our script from now on. We know that our script's loaded in, we know it's gonna be loaded in, it was loaded in, but we're just gonna focus on our body element, which is describing the overall page and is there in our DOM by default, and that's it.

That'll do. Now let's get into our JavaScript. So we have a memory. I don't even appreciate enthusiasm, which I repeat the exact same thing, 20 times. Our memory, isn't that fantastic? Let's put our call stack straight on here. Cool stack. There it is. There's our event loop to determine whether to load things from our callback queue which becomes of course extremely pertinent here, because we're going to have functions called back to run JavaScript code, to engage with the change data or the action.

Sorry that the user has taken. We could even because it's not a closed system, mention here immediately that our user can take actions that will determine what executes in our system, user action. We don't have any user actions happening yet, but we will. Okay, now in JavaScript, help me out justice.

What is our object? Our mission critical object that loads straight into JavaScript on its runtime beginning. Good to be kicked off. What happens? What's gonna be loaded into its memory?
>> On line one.
>> As soon as JavaScript runs, we automatically get available to us.
>> Yeah, the Document Object

>> Brilliant, with a bunch of useful functions. We're gonna use a different one this time. Can you spot which one we're gonna use this time?
>> We got the replace child.
>> Spot where that's been.
>> Sorry, the set interval. Line 19, Is that where we're looking?
>> No worries, have a look at line 4 and 6.

Can you spot what method we might be using on document?
>> The create element.
>> Create element, exactly. That's one of ours. We also got, as you say in line 12, what looks like a getter setter property. Can you spot what it is?
>> Well, so if there's nothing on in the body it's gonna be-

>> Well, yeah, but what's the property called?
>> Replace children.
>> That's gonna be available once we have? Exactly. So what's gonna be on our document object? It's our body getter setter property. Which is gonna know where to go because, It's gonna know where to go because we have a hidden link to the DOM.

The full list of elements and any of these getter setters like body or functions like create element are going to first check where they're accessing in C++. Okay, now we're set, Justice. In line one, we actually have three lines of code that are separated by semicolons. Just to save space, there are three separate lines.

This is not me initializing multiple variables in a clever one line way, this is three separate lines. What are those three that we are? And the reason I do this, by the way, people, is just for diagramming. To keep things simple, technically we'd probably encapsulate, protect many of these pieces.

We'd probably declare them locally in Data to View or parse them as an input to Data to View. The reason I do them here is so that I don't need to deal with my favorite concept in JavaScript, closure. While a wonderful concept, it's gonna be much harder to diagram.

So I just put everything in global. In practice, we would probably, certainly not. But just for diagramming purposes it lets us easily diagram basically, easy as that. Okay, so what are those three variables which we're declaring there, Justice?
>> We've got a post-
>> Okay.
>> Which is empty string.

>> Both is an empty string, perfect. Next one, [INAUDIBLE]
>> A JS input.
>> Beautiful, we're not assigning it anything yet. I never mean to do that so I know I did plus or equals. Because I always think of equals as a command what whereas what we're doing here is we have stored.

This is the result of the command assignment. I never use equals in the memory, I mean, Cola has a downside as well because Cola looks like an object property key value pair, but I never liked using equals in this memory because it's a command to go and assign something.

So I never think that should be equals but anyway, okay. JS input is well, on signed uninitialized and then just did the same. So there we go. I'm putting them there only, as I say, for diagrammatic purposes, but now let's declare some functions. Both our mega function here now that's doing all of the creation of anything that's gonna be seen by the user, but conditional on data in JavaScript.

Wanna work out what the user sees? Go look at the data and go look at the one place that pipes it through to the view, the dataToView converter. And then a handler which is our other type of function we can have in UI. One, or at least in this structure, one is the take the data, display it.

The other is the user takes action, pinpoint change some data based off that action, and do nothing else. Okay, let's say those two functions, Justice.
>> I have got the data to view.
>> Yep, perfect.
>> And the handle.
>> And handle input. Okay, and now we start our process of looping essentially running data to view which is gonna convert any change data here on rotation.

And we set that up by calling what, Justice?
>> Set interval.
>> Yeah. Which is going to do what?
>> It's gonna take the reference of data to view.
>> Beautiful. I don't know why I did another line there, sorry. And what argument, how many milliseconds?
>> 15.

>> 15, yeah, spot on. That's going to pass that to our timer feature on the web browser, implemented somewhere between JavaScript and the browser, it's C++ environment. But what we do know is, the waiting for that 15 milliseconds of pause in order to execute data to view, is not happening in JavaScript and blocking anything in JavaScript running.

It's absolutely not happening there. So we're setting up an interval of 15 milliseconds in which we're going to see our Data To View function, DTV, be called back at 15 milliseconds into JavaScript. In the meantime, that finishes executing. I like to draw a line through to make it really clear.

That is done.

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