Declarative UI as a Paradigm

[00:00:00]
>> Declarative UI as a programming paradigm. Goal, see a JavaScript nested, this is where it gets really fun, we can have elements in here in the content section, we could totally put sub-elements in there. That would then show up, hopefully, if we wrote the code, as sub-elements nested on the DOM tree on the list of elements, and therefore it'd be inside, and that's where we can expand how this is gonna work.

[00:00:25]
And we will go see a JS nested list representation of your actual DOM elements and content so you can get semi-visual coding. It's very contemporary emoji choice there, right? Via nested objects or arrays of info, as we default to in UI Hobarts, all functional components, which is what we're gonna come to.

[00:00:46]
We can create these via functions that produce them as the output. For it to be guaranteed accurate and not out of sync, we need the data in JavaScript to be the only source of truth. That's gonna allow us to have a function that runs through and produces a representation in JavaScript, first, of what's gonna show up with the actual data, and know that there's nothing else that could be showing up on here that is not from this source of truth in JavaScript.

[00:01:17]
If you set up one way data binding, that is a user can only affect data via the handler, and then run the update all the way through, otherwise, it's not guaranteed to be reflective. You could have things here that maybe have come through our handler, or things here that are from the user, where in fact we want any user action just to be a submission.

[00:01:36]
Imagine if the user wrote y here and we were not filling that through back to JavaScript? Then this VDOM here would not have our latest update submission from the user of y. Instead, we would just be left with the text still being empty because we have everything on the page being dependent on what's in JavaScript data.

[00:02:01]
We're able to describe it in full in JavaScript as a kind of intermediate step before it then gets rendered on the DOM itself. Yeah, so we literally take any change to the DOM, we've said this multiple times today. I just literally to wanna, honestly, these notes are as much for me as anybody else.

[00:02:18]
So we literally take any change to the DOM, e.g, user action typing in letters in an input field and immediately replace it. Of course, as we said earlier, we can handle this slightly differently if we wanted to embrace this, immediately replace it by sending the info to a data store in JavaScript.

[00:02:37]
Let's even actually map this out with some letter. So we have tended to here, and then the data flows in the JS DOM or visual DOM, convert that to the actual DOM. That's what's happening here, where we create our access to objects, and it comes to the actual DOM.

[00:02:58]
We have semi-visual coding, our JavaScript DOM or visual DOM content and positioning on the page in JavaScript is reflected in our actual view. We declare, A, what the page structure we want, and B, how you want its content to depend on data, and then it appears on the page.

[00:03:14]
Even an empty form field is a propagation of data, or empty string in this case. So our action from the user comes through, changes our data via our handler, and then we run our converter through. But as we heard yesterday from Magic, yes, although the data does flow this way, think of this as being a pinpoint submission of, precisely, please take this new information and determine if you want to update the data in JavaScript.

[00:03:43]
We get to define that in our handler. Do not get involved in the automatic re-propagation of that to the page based on the permanent description of that one-to-one relationship between that data and what we see.