Skip to content
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] Tree structure of parts in the DOM #992

Open
tbondwilkinson opened this issue Mar 21, 2023 · 3 comments
Open

[dom-parts] Tree structure of parts in the DOM #992

tbondwilkinson opened this issue Mar 21, 2023 · 3 comments

Comments

@tbondwilkinson
Copy link
Contributor

tbondwilkinson commented Mar 21, 2023

@justinfagnani @mfreed7 @sorvell @kevinpschaaf and a few folks from Angular have been thinking about the DOM parts API fresh.

In the current DOM parts proposal, there's no concept of being able to walk a "tree" of parts in the DOM. Because users create part objects, they're mostly used as an update mechanism rather than a structural mechanism.

Considered with #990, if DOM parts are something that is attached to the DOM and can be constructed by the browser, it makes sense to propose that parts should also form a tree structure and each part should have a parent and children.

Updating a subtree of the DOM

If the only place to get parts for the document is to call getParts() on the DocumentPart, it's much more difficult to do a partial render update for only a portion of the subtree. If a ChildNodePart has a getParts() method, it's easier for that portion of the tree to be walked and updated independently. Most frameworks do not walk the entire document on every update, and allow partial rendering and skipping rendering for subtrees.

Nested templates

This becomes even more important for templating approaches that can be nested.

<html>
  <?node-part classes>
  <div id="parent">
    <?node-part src?>
    <div id="icon">
    </div>
    <?child-node-part content?>
    <div>
      Pre-content
     <?child-node-part greeting?>
     <span>Hello there, <?child-node-part name/?><span>
     <?/child-node-part?>
     Post-content
    </div>
    <?/child-node-part?>
  </div>
</html>

This might be HTML generated for template with nesting

function page(name: JSX.Element, src: string) {
  const greeting = <span>Hello there, {name}</span>;
  const content = <div>Pre-content {greeting} Post-content</div>;
  const html = (
      <html>
        <div id="icon" src={src}><div>
        <div id="parent" {classes}>
          {content}
        </div>
      </html>);
}

If ChildNodePart can also be a PartRoot with a getParts() method, then each nested <template> can be the part container for its parts and can be walked independently of the rest of the DOM.

For more about how this fits into a broader DOM parts proposal, see this new proposal based on DOM parts

@keithamus
Copy link
Collaborator

keithamus commented Apr 21, 2023

WCCG had their spring F2F in which this was discussed. Present members of WCCG identified an action item to take the topic of DOM Parts and break it out into extended discussions. You can read the full notes of the discussion (#978 (comment)) in which this was discussed, heading entitled "DOM Parts API".

As this issue pertains to DOM parts, I'd like to call out that #999 has been raised for extended discussions and this topic may be discussed during those sessions.

@rektide
Copy link

rektide commented Jul 29, 2023

ServiceWorker had a longstanding issue requesting a DOM in w3c/ServiceWorker#846. The issue was closed with a similar note to what's happening here, saying ServiceWorkers wasnt the right forum for the spec, and pointing out that DOM has a lot of rendering-related capabilities (like getclientrects) that would need to be nulled out for success, and referring the issue to https://github.com/whatwg/dom for follow-up.

I don't think that follow-up ever happened with Service Worker folk. Has any follow-up happened in this group? This seems like a hot-potato, cross-sectional issue for the w3c but seems to keep being dropped.

@sashafirsov
Copy link

sashafirsov commented Jul 31, 2023

From prospective of the frameworks needs, the traversal is just a part of more general solution: the DOM with template render results merging.

Browser would perform this operation way more efficient then JS as has ability to use threads on simultaneous DOM sub-trees inspection. Of course if exposed to JS API would have async nature.

As the detached DOM just have to follow the Node interface, the data layer for it could be served by wrapper from the POJO HTML presentation, virtual DOM, XML, etc.

Going further, as the data to detached DOM transformation can be a streaming/ multithreaded process, the API can be exposed as the template engine method which instead of rendering own result would merge the results into live DOM.

🤔 Perhaps it worth to propose the API for merging the alive DOM with detached one?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants