You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would like Greenwood to come up with a native solution to HTMLElement SSR rendering, coming out my conversations in the Lit repo - lit/lit#2092 (comment)
The goal would be to leverage Declarative Shadow DOM and provide a default alternative to puppeteer, and moving puppeteer to a custom plugin instead, including all the @webcomponents polyfill dependencies. Effectively this is providing a Next.js like pages experience, but for native custom elements.
Details
I suppose there are two outcomes from this:
Server rendering your client code (e.g. prerender + static)
As part of wcc, we could potentially allow a custom element to be the export and Greenwood can use renderToString to get the final HTML.
Because of how wcc works, we should be able to get card.js back as metadata that we can feed into the bundler, which means there would be no need to specify it via <script> tags in the template, which means this could potentially usurp the need for getTemplate and getPage?
The text was updated successfully, but these errors were encountered:
Type of Change
Summary
(grabbed some of this from #926 )
Would like Greenwood to come up with a native solution to
HTMLElement
SSR rendering, coming out my conversations in the Lit repo - lit/lit#2092 (comment)The goal would be to leverage Declarative Shadow DOM and provide a default alternative to puppeteer, and moving puppeteer to a custom plugin instead, including all the @webcomponents polyfill dependencies. Effectively this is providing a Next.js like pages experience, but for native custom elements.
Details
I suppose there are two outcomes from this:
export
and Greenwood can userenderToString
to get the final HTML.Because of how
wcc
works, we should be able to get card.js back as metadata that we can feed into the bundler, which means there would be no need to specify it via<script>
tags in the template, which means this could potentially usurp the need forgetTemplate
andgetPage
?The text was updated successfully, but these errors were encountered: