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

noamr 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 comments in templates anyway.

I get that for this use case. The proposal here is more general and not tied to templates.

> 
> 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.

DOM parts allows you inserting markers into <script> and <style>?
I mean we can also develop marking comments in CSS/JS as well but I'm not convinced it's necessary.

> 
> 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.

The idea is that you can most all of this efficiently with addressable comments, without having to walk the tree.
You can apply your own semantics to comments, like "the node range between those markers means something" or "the parent element of this comment means something" or whatever.

>    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.

Yea but `getMarkerCommentsByName` is recursive and cached ahead of time by the parser, so this might be much more optimized?

> 
> 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.

I wouldn't assume that it only supports child ranges. Child ranges are just a main use I had in mind.



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

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