-
Notifications
You must be signed in to change notification settings - Fork 371
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
Allow customElementRegistry definitions to persist across page loads #1033
Comments
I wonder if this is something that could be added into the scoped customElementRegistry proposal, @justinfagnani? |
In which JS realm would the component definitions live? I think we need declarative custom elements for this. Implementations could cache at least the source code for definitions (possibly even in pre-parsed/binary format, very similarly what Firefox used to do with XBL). |
I think we should start with a more general-purpose mechanism to cache the pre-parsed/binary format of a given library. That seems like a pre-requisite to doing something Web Components specific. |
I was initially thinking this would allow storing element instances and re-using them across page loads (having their This would require some semantics of Service worker, with considerations for how to bust the cache on app updates. Maybe a ServiceWorker would even be responsible for this, like maybe it would manage a pool of elements. Maybe it would only be position if an element does not reference anything from its previous Realm, and only grabs things from the new When an element would be garbage collected (or when the page is being destroyed) this would be an opportunity for some API in the SW to be called with the element that is no longer needed in the main thread. Totally just imagining here, not really sure how feasible this is, but the idea seems interesting. |
Piggybacking on idea... Looks like we are on the edge of breaking the DOM passing across threads prohibition rule. The WC Library ( and in general any ) could have a use for bundle globals initialization and keep as registry for this lib as the implementations. Lib URL would serve the artificial context(hidden page/thread). The consumer page would refer the lib by URL on one of layers enabling its custom elements there. The life cycle would start with 1st use and close upon session termination with ability to discard any time on browser discression. Of cource there would be no domain nor document in the scope of WCL. Those would become available only during WC instantiation. Such restrictions can be lifted if lib domain and consumer page match. WCL would encourange CDN kind deployments and reuse. With security ^^ in place, preloadingas usual via embedding into scope of WC
dedicated
|
Not necessary. If we deine imperative registry API as self-registering in current context, there would be no need for any server side special handling. Plain import JS module with payload like following suffice: // WCL
export defalut function register( contextComponent, tagmap={} ){
contextComponent.define(tagMap["my-custom-element"] || "my-custom-element", class MyCustomElement{ ... } )
contextComponent.define(tagMap["my-another-element"] || "my-another-element", class MyLuckyElement{ ... } )
} // caller
import someLib from 'path/wcl.js'
// within component ...
someLib.register(this) disclaimer: syntax is not exact, just an idea |
I'm not really understanding how FOUC is related to web components. FOUC is a general problem which can occur if the parser yields and paints before any expected state, either before some script that performs rendering has run or even before the HTML/CSS has all streamed in. And, typically upon page-refresh the browser's cache will pull in these resources which should typically result in no FOUC. |
One of the biggest drawbacks of using web components is the flash of unstyled content (FOUC) following the page load but prior to web components being defined. Additionally, when loading multiple web components as modules pages go through a considerable amount of cumulative layout shift as each component is defined, styles are reevaluated and layout is recalculated.
While server-side rendering is an option, it has several drawbacks:
It seems to me all these problems could be mitigated by allowing component definitions to persist across page loads within the same domain, similar to how data can be stored client-side in sessionStorage and localStorage. In this way, a first visit to a site using web components bears the weight of LCP & CLS metrics, but each successive page load is faster as the components are reused.
The text was updated successfully, but these errors were encountered: