Re: [WICG/webcomponents] Addressable comments (a very small DOM parts subset) (Issue #1116)

justinfagnani left a comment (WICG/webcomponents#1116)

I see the edit to add a query API.

Honestly, `ParentNode.getComments()` would work just about as well for us. We can easily filter out comments that don't match our comment format. There are usually very few non-markers in comments anyway.

But to analyze this API against DOM Parts (or really Template Instantiation), being only able to address child node ranges isn't all that useful because we have to visit and insert markers for attributes, inside rat text elements like `<script>` and `<style>` and ideally recurse into nested `<template>`s.

There two big places we'd like to optimize with something like parts:
1. Attaching parts to the template. Right now we have to insert markers of the appropriate type (comments where we can, text in unquoted attribute values, comment data, and raw text elements), create the `<template>`, then walk the template content to find the markers. Because this is only comments it doesn't eliminate the tree walk. We would still have to have a walk for attributes, raw text, comments with bindings in them, and `<template>`s.

  You can see this code [here](https://github.com/justinfagnani/dom-templating-api-proposal/blob/main/packages/dom-templating-prototype/src/lib/template.ts#L89)
2. Finding markers in cloned template instances. This requires a simpler tree walk because we're recorded the preorder DFS index of all the nodes that have attached parts. It could maybe be useful here if we insert these markers instead of recording the node indices. It's not much code that we would save (example [here](https://github.com/justinfagnani/dom-templating-api-proposal/blob/main/packages/dom-templating-prototype/src/lib/template.ts#L229)) - instead of iterating on a TreeWalker we'd iterate through the comments returns, so maybe a couple of lines - but maybe it'd be faster. The biggest hope we have for a boost is that we don't create JS wrappers for nodes we don't care about.

So I don't see that this, or NodeGroup, or any DOM Parts alternative ideas that only supports child ranges is that useful of a substitute for DOM Parts or Template Instantiation.

If this ended up being faster than a TreeWalker, and that was because of fewer Node wrappers, I think it'd be very powerful to explore a new TreeWalker API that supports more declarative node filtering. A filter object with regexes that can run on tag names, attribute names and values, child text, and comment data, would let you pull out just the comment nodes you care about and more.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1116#issuecomment-3528685100
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1116/3528685100@github.com>