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

FrameMuse left a comment (WICG/webcomponents#1116)

Honestly, I wanted to propose something like Comment Attributes as well. I went through this little discussion and now I see the problems too.

I see that the problem that is being solved with Comments is Hydration, which requires **markers** somewhere in a HTML string and they must be **indexed**.
I refer to **Hydration** as a process where you evaluate anything you previously left in HTML with a potential to be addressed.

What I feel like would help is some kind of `CommentObserver`, so one can conditionally attach a listener to a certain element (it should be performant enough to be added to the root document element). There should be also `CommentWalker`, which should efficiently help to filter out desired comments.

Or something like `CommentRegistry` can be introduced including both, so that we can track and access comments from a `WeakSet` or maybe even `Map` by giving a pattern that should be used to group comments under a certain format.

```ts
class CommentRegistry {
  constructor(predicate: (commentName: string) => string | null)

  readonly set: WeakSet<Comment> // Includes all filtered comments.
  readonly map: Map<string, WeakSet<Comment>> // Groups all filtered comments by given group key.
}

const commentRegistry = new CommentRegistry(commentName => {
  if (commentName === "$lit1") return "lit1"
  if (commentName === "$lit2") return "lit2"
})

document.body.append(new Comment("$lit1"))

for (comment of commentRegistry.map.get("$lit1") ?? []) {
  doSomething(comment)
}
```

It would do indexing at the moment when Comment Node is parsed or added to the document (after `commentRegistry` is initialized to avoid unnecessary overhead), which could be a better strategy than "at the moment query", but maybe I'm missing something.

---

As for DOM parts, if narrowing to the least primitive, I think it should be either Custom Comments (like Custom Elements), so that they can be tracked or anything other that do node connection tracking.

Because if an element or a comment is detached, you're cooked, you can't do anything about, but if you have tracking, you can replace a "gone element" with a Comment Node to replace.

So it's not that we're missing Comment Attributes - we can implement it on our own, but it's the problem that we lack control of DOM itself - we can't "customize" the tree.

That's why we propose something that can be put into the DOM, being a point of connection to elements and invisible to basically anything except the owner. This is just a pursuit for more control over DOM tree behavior. IMHO.

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

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