<teleport> element #9614
Comments
|
Sounds a bit like slots: <body>
<tele-port>
<template shadowrootmode="open">
<slot name="replace"></slot>
<slot></slot>
</template>
<div class="body">
<h1>The rest of my web page goes here</h1>
</div>
<!-- a bunch of async ops -->
<div slot="replace">new content gets streamed out-of-order!</div>
</tele-port>
</body> |
|
Hey @CyberAP, I'd recommend focusing on 1 and 2 of https://whatwg.org/faq#adding-new-features for now and to try and flush those out. A new element needs quite a bit of justification and ideally there's ample precedent for it in userland. |
|
Thank you @annevk! This makes sense, sorry for not paying attention to the FAQ first, I've tried to address your concern. |
|
@keithamus good point! The problem with this solution is that you basically have to wrap your whole app within a Web Component and you also have to know where to place the slots in advance, which is not possible in some cases. I did not manage to test whether declarative shadow root contents get replaced without buffering though. Edit: it works! Though the limitations mentioned above still apply. |
|
@CyberAP Would using iframes help solve this problem for you? If async rendering is enough of a concern for you application to solve for (due to computationally expensive parts) then perhaps this hinting that those particular pieces should be considered separate resources with their own URL on your server. For example: <body>
<div>start of content here</div>
<iframe src="computationally-expensive"></iframe>
<div>rest of content</div>
</body>Are there constraints you see this imposing that wouldn't work for you case? |
thoughts re
|
You could use a
Could you describe some of these?
As far as I understand it any new element would have similar issues with pre-existing tooling and libraries. I’m struggling to see how creating a new element would not suffer from the same issues. I’m not advocating for using ShadowDOM for this case, but I am curious what the specific barriers are; it would help establish motivation/justification for a specific solution to this use case, as well as help establish some criteria/constraints. |
keithamus
added
addition/proposal
@keithamus the main issue is styling. You have to put your primary content into a Also, you can not stream content before you close the |
|
Why would you need to style inside the shadowroot? The shadowroot just contains two slots so everything is in light DOM. |
|
@keithamus how you define deep slots outside of shadow root? This won't work: <tele-port>
<template shadowrootmode="open">
<slot><slot>
</template>
<div class="body">
<slot name="replace"></slot>
<h1>The rest of my web page goes here</h1>
</div>
<!-- a bunch of async ops -->
<div slot="replace"><div class="foo">new content gets streamed out-of-order!</div>
</tele-port>You have place your primary content inside the shadow root in order to do this. |
|
Why can't you move the shadowroot to the <div class="body">
<template shadowrootmode="open">
<slot name="replace"></slot>
<slot><slot>
</template>
<h1>The rest of my web page goes here</h1>
<!-- a bunch of async ops -->
<div slot="replace"><div class="foo">new content gets streamed out-of-order!</div>
</div>Issue #10273 talks about slotting indirect children and so might be an option to explore here also. |
|
@keithamus this only works if you place the slotted content within the wrapper element, which defeats the purpose. This now becomes a blocking operation: we can't continue streaming the rest before we resolve the slots. |
and others
It would be nice for HTML to provide a native
<teleport>element that would render its contents at the target destination instead of in-place. This mostly applies to when the document is still streaming.Motivation
Right now there's no mechanism to redirect the underlying document stream to another part of the document. This means you can only write to the end of the document. This is quite limiting because sometimes a part of the document can be computationally expensive to render on the server or could take long to serve to the client. In order to solve that we can show a temproary placeholder in place and replace it later as soon as we get the HTML. There are solutions that can solve this problem already but they have their limitations:
<script>rendered within a new document stream does not execute).With a
<teleport>element we shouldn't have any of the downsides listed above and it would also siginficantly simplify current solutions to the problem that involve complex code on either a client or a server. The introduction of this element should also open up a new class of streaming-first solutions to web apps.The text was updated successfully, but these errors were encountered: