Parts and Template Instantiation
Facilitator: Ryosuke Niwa
Discussion of APIs to help instantiate templates.Minutes (including discussions that were not audio-recorded)
Transcript
Well, welcome everybody.
My name's Han, and, I'm from Google.
And this is a DOM Part API that Ryosuke, Tess, Justin, Mason and I worked on it, with a few (unintelligible muttering).
Next slide, please.
Yeah, just to give a little background, so template instantiation was initially proposed by Apple in 2017, and it generated a lot of interest, so I have some slides here.
Or some links to the different discussions.
The outcome of that discussion in 2017, and there was another, further-on discussion in 2019, was that the initial proposal was too broad, because it included syntax, parts, and template processors.
We want to focus mostly just on the DOM Parts API, to have a little more scope around that area.
And so that it can, ah, be basically released; it's easier to actually release that.
Okay, next slide please.
So, why do we wanna do this, right?
And so for the DOM APIs, there's really no easy way to update large chunks of HTML.
So for one, we wanna provide a better way for web developers to update different chunks of HTML, so better economics.
Another way is we definitely want to improve performance for these updates, so this proposal includes batching of multiple DOM updates, for performance.
And we want it to be, to easily clone a DOM tree that has parts attached to it for repeated updates.
So you can think of it as a tree or a list, with just a template instance, or just a node instance where you want to repeatedly update with data.
So that is the reason.
Next slide please.
And in terms of features, so we want to scope this, what will be part of this DOM API, versus what is for the future, and not discussed in this API.
So, the features include like inserting and replacing content at the specific location of DOM tree, updating multiple parts of the same attribute, so if you have an attribute with different parts, they can be updated at the same time, updating JS properties, so that is a big ask from the initial proposal by the framework authors, that this is a critical feature that's needed, batch updates, we want to basically for performance reasons batch all the updates together, and lastly: clone node tree with parts.
So once you have inserted your parts into a node tree, you wanna be able to clone that node tree with different parts and continued updates.
(indistinct) For future discussion, and not included in this proposal, is: expressions within the DOM Parts, conditionals like if-else, loops, and then template processing model from the previous, ah, proposal.
Next slide, please.
So, what is a DOM Part?
A DOM Part is unit of mutable state in the DOM tree.
So it can represent an element's content attribute.
It can also represent a node's children, or a partial, and it can represent the whole children of a DOM node, or partial children of a DOM node, sometimes.
And also, JavaScript properties of the element.
Next slide please.
Okay, here is the API.
So, we have a part, you can set its value.
We'll get, in the next slide we'll see, how setting the value doesn't actually automatically commit the value into the DOM tree.
So there is a commit function or method.
There's a node part, which, this part is associated with the node.
There's an attribute part, where this part could be associated with an attribute.
And a child node part, which then it's representing a portion of the children.
That's associated with the node.
Next slide, please?
So, how does this actually work?
So here's an example of that.
In the example, HTML is used just for reference.
So we don't have the syntax, so this is just for illustration.
You can see that there is a name.
And there's email.
So there's a node part, an attribute part, and also another node part.
So how do you construct this?
So in the JS, you would, ah, create the node parts, assign the value, C, and the value, when you assign the value, this is what we call staging the value.
So the value is actually associated with the part, but it's not committed into the DOM tree.
And it's only committed once you commit, so for each part, you do commit, the value is written into the DOM tree.
And the result, we see, is the HTML with all the values being inserted into the DOM nodes.
Okay, next slide.
Here is the property part, and this is one of the most consistent feedback, from the original proposal.
But the consideration for supporting this feature, property part, is that we don't want to jump back and forth during the commit phase.
So, meaning that when you're doing a batch commit, you don't want to, because the property part actually can require JavaScript if it's a custom element property, so what we'll want to do is we would want to batch all the commits, or DOM mutations, up front, and then we'd want to add an enhancement to the customer element callback reaction, call this property reaction, and this property reaction will be called after the batch DOM mutation has been finished.
Then, you will call the custom reaction queue for attribute setting, attribute change callback, property, reaction; so in the property reaction, that's when the property has been set, and the JavaScript associated with that property, the setter, has been revoked.
So, if we look at this example here, you have A and B, and so A is a customer element, and this customer element in line two on the example, it shows attribute value, then go to line four, a property value.
And an attribute, eh, an attribute value too.
So how it would happen is that actually it will be set, the customer reaction queue will be kicked off, depart, and you will get attribute change callback, then property, the reaction for a property, and then attribute change callback again for the second attribute.
Next slide, please.
So batching.
So, the original proposal was to tie to a template.
And the feedback from that is that, excuse me...
Web developers does not want this to be tied to template.
So the alternate proposal, this proposal, is that we create a new parts group.
The parts group can take a sequence of parts that the developer has created, from a DOM node.
So why do we wanna do this?
One of the things that we know is jumping back and forth from JavaScript to user, into DOM mutations, and then back to JavaScript, that's very costly.
So we want to batch all these updates.
And we wanna batch the updates for all the different parts.
So, we think that there is a pretty big performance gain from this.
And so it's very easy to create a part group as a library object, and you pass the parts that you want associated with this part group in the constructor.
Once you set the value of the parts, you can call commit on the part group, and you will commit everything into the DOM tree.
And last slide.
Next slide, please.
So, cloning.
We want to introduce a new API clone tree.
Which allows the developers to be able to, once they mark up a node and its tree, with the different parts, so the clone tree will allow the developer to pass in an option to say that: hey, I want to clone this tree.
And I want the parts to be associated with the clone tree, and they will be added into the parts group that you've added into the API call, as the clone options.
You will get back the node, and also the clone node plus all the parts that's associated with that clone node, into the part group.
And I think this will be a big improvement when, for example, on some use cases like if you have a table, you wanna be able to update each row of the table, so you wanna clone an update, or a list, for example.
Okay, this is the end of my presentation.
I know Ryosuke's proposal goes much more in-depth, but this is just a high-level view.
So it's easy to see and, ah, basically we can open up for discussion.
Also, I wanna say that even though it's a collaboration, but Ryosuke did most of the heavy lifting, on writing up the proposal, so big shout-out to that, to Ryosuke.
Thank you.
