-
Notifications
You must be signed in to change notification settings - Fork 370
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[dom-parts] Creation API #1010
Comments
For This signature is a little “forgettable” to me and I wonder if dictionary ChildNodePartInit {
required Node parentNode;
Node? previousSibling = null;
Node? nextSibling = null;
}; (If the parent is required to be “in agreement” with the siblings at construction time, then Another possibility would be something like dictionary ChildNodePartOpts {
Node? nextSibling = null;
Node? previousSibling = null;
};
interface ChildNodePart {
constructor(Node parentNode, optional ChildNodePartOpts opts = {});
// ...
}; ...which seems fairly natural if both of the “opts” options are actually optional/nullable but the parent node isn’t. |
I'm interesting in particular in what happens if the nodes the |
Yeah this is something I've never understood with this API idea, it seems like it'd be simpler instead of the proposed i.e. If we had a template like: <div>
<b>Hello </b>{{name}}!
</div> then some template parser would just generate this: const namePart = new PartialNodeChildListPart();
const childListPart = new NodeChildListPart(divElement, [bElement, namePart, "!"]); committing a change would effectively just be the same as setting the child list of the div. (Though internally committing would deal with the |
We need to decide on the exact shape of API to create DOM parts.
Current proposal:
The text was updated successfully, but these errors were encountered: