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

EisenbergEffect left a comment (WICG/webcomponents#1116)

@noamr I thought it would be good to see another real example of what frameworks do, to help frame this conversation.

Yes, it boils down to element locators and "range" locators. So, what might be helpful is a single API that will give us me both.

```html
<template marked>
  <form marker="A">
    <input type="text" placeholder="description" marker="description">
    <button type="submit">Add Todo</button>
  </form>

  <ul>
    <!--marker B-->
  </ul>
</template>
```

Now my node locator and behavior binder can simplify to this:

```js
const n = root.getMarkers(); // should work on shadow root, fragment, document, element
__listener(v, n.A, $event => this.addTodo($event), "submit");
__forOfBehavior(v, n.B, () => this.todos, itemTemplate, this, createItemScope, void 0, emptyTemplate);
```

If I have to use one API for elements and another for comments, and then piece them together, that's not great. It would add complication and potentially more code than I have today.

If the performance isn't competitive with my ahead-of-time compiled node location code, then while it's still valuable, it's not something I would use, nor is it something that a lot of compiler driven libraries and frameworks would use (e.g. Solid, Svelte).

There's another complication here as well. As mentioned above, in the case of the `{#for}` scenario, we're going to have multiple sibling views rendered on the server. So, a simple id won't suffice. We would need other metadata to group those. Of course, this can be done with a library-specific `data-` attr on elements, but what about comments? There needs to be some way to embed extra data in that case. I suppose the marker's data could be manually extracted by the framework. But now, we're left with the library still having to:

* Parse its own format from the comment text.
* Parse its own format from a library-specific `data-` attribute.
* Manually group collections of markers.

Of course, I already do all of this as shown above. So, the platform isn't helping me much. Again, for this to be realistically adopted by existing libraries, it must:
* Not result in more complicated framework code. Preferably, reduce and simplify my code.
* Perform competitively with existing solutions.

I *think* this is trending in the right direction, assuming the performance can be handled (actually quite a bit assumption when competing against compiler optimizations), but I also think we need to explore more:

* An API that finds all markers (both elements and comments)
* A standard way of embedding metadata (something like the OP's key/value suggestion) that the browser can parse and make available on demand.
* Nested/grouped ranges

Since I have an existing framework that works and *is very fast*, and because that's true of a significant segment of the community, a proposal like this has to be strong enough for library authors to justify re-writing their compilers and runtimes and betting their businesses and community future on it. I don't think we're there yet, but I'd like to see us continue to explore further.

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

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