feat(ssr): shadow dom components can render as declarative-shadow-dom or as 'scoped' #6147
Conversation
Co-authored-by: Christian Bromann <[email protected]>
Co-authored-by: Christian Bromann <[email protected]>
Co-authored-by: Christian Bromann <[email protected]>
johnjenkins
changed the title
Co-authored-by: Christian Bromann <[email protected]>
Co-authored-by: Christian Bromann <[email protected]>
Co-authored-by: Christian Bromann <[email protected]>
|
@christian-bromann I had to un-deprecate |
There was a problem hiding this comment.
I've been running some tests and discovered that the order of elements within the light DOM differs between DSD and scoped mode, e.g.:
import { renderToString } from './test/wdio/hydrate/index.mjs';
const { html } = await renderToString(
`
<ssr-shadow-cmp>
<p>Default slot content</p>
<p slot="client-only">Client-only slot content</p>
</ssr-shadow-cmp>
`,
{
fullDocument: false,
serializeShadowRoot: true,
constrainTimeouts: false,
prettyHTML: true,
},
);
console.log(1, html);would return:
<ssr-shadow-cmp class="hydrated" s-id="1">
<template shadowrootmode="open">
<style>
:host {
display: block;
padding: 10px;
border: 2px solid #000;
background: yellow;
color: red;
}
</style>
<div c-id="1.0.0.0">
<slot name="top" c-id="1.1.1.0"></slot>
<slot c-id="1.2.1.1"></slot>
</div>
</template>
<!--r.1-->
<p>Default slot content</p>
<p slot="client-only">Client-only slot content</p>
</ssr-shadow-cmp>But when setting serializeShadowRoot: 'scoped', I get:
<ssr-shadow-cmp class="sc-ssr-shadow-cmp-h hydrated" s-id="1">
<!--r.1-->
<!--o.0.2.-->
<!--o.0.4.-->
<p slot="client-only" hidden="" c-id="0.4">Client-only slot content</p>
<div class="sc-ssr-shadow-cmp sc-ssr-shadow-cmp-s" c-id="1.0.0.0">
<!--s.1.1.1.0.top-->
<!--s.1.2.1.1.-->
<p c-id="0.2" s-sn="">Default slot content</p>
</div>
</ssr-shadow-cmp>Note: the order of the slots changing.
|
I think that makes sense @christian-bromann in 1, the shadow dom is separate from the light dom and the browser takes care of how it’s rendered. The in 2, there is no shadow dom so the dom gets resolved and rendered as it appears as a light dom tree. The |
|
Yep - will do tomorrow |
christian-bromann
removed this pull request from the merge queue due to a manual request
What is the current behavior?
When generating a
shadow: truecomponent during SSR, Stencil renders a Declarative-Shadow-Dom (DSD).Generally, this is preferable as it's natively supported in most browsers.
There are some scenarios at present, where DSD is not ideal:
(* e.g. given
my-list-itemcomponent which is rendered 20 times. DSD will render 20<style>tags which can negatively impact the initial weight of the page - especially without compression.)GitHub Issue Number: N/A
What is the new behavior?
The ability to use Stencil's
scopedbehaviour has been extended for use during SSR.During SSR a
shadow: truescoped component will be rendered without atemplate- just plain, lightDOM html and a single<style />tag added to the<head />.On the client, these lightDOM nodes get added to a new shadow-root and the
<style />tag is added as a `constructible stylesheet'.To this end, the
serializeShadowRootoptions (passed intorenderToString()) now accepts a number of new options:'declarative-shadow-dom'- will render allshadow: truecomponents as DSD'scoped'- will render allshadow: truecomponents with Stencil's scoped behaviour{ 'declarative-shadow-dom': ['tag-1'], default: 'scoped'; }will render component tagstag-1with DSD, but all others with Stencil's scoped behaviour{ 'scoped': ['tag-1'], default: 'declarative-shadow-dom'; }will render component tagstag-1with Stencil's scoped behaviour, but all others with DSDfalse- will disable all SSR render behaviour forshadow: truecomponentstrue- DEPRECATED will render allshadow: truecomponents as DSDDocumentation
stenciljs/site#1507
Does this introduce a breaking change?
Testing
Other information