[scoped-custom-element-registry] No support for isomorphic scripts

[jonathandewitt-dev]

Description

I'm attempting to render DSD for web components on the server side. It's difficult to support scoped elements, however, because the polyfill is not server-friendly.

The polyfill must be statically imported before my code; conditionally loading the polyfill does not work.

Example

Simply import the library and launch the script using Node.

// example.js
import '@webcomponents/scoped-custom-element-registry';

node example.js

Expected behavior

No error should be thrown. Script should be ignored on the server.

Actual behavior

ReferenceError: ShadowRoot is not defined

Version

0.0.9

[sorvell]

There's currently no platform support for scoped custom elements in DSD. You'd have to use a polyfilled version of DSD for this to work. Because of this, it seems like there's really limited value in making the polyfill work in Node at the moment.

However, if you just want it to not produce an error, this seems reasonable and we'd welcome a PR for this.

[jonathandewitt-dev]

That's perfectly fine, all I'm looking to achieve is importing without throwing errors. I'll work on a PR!

[sorvell]

It's unclear why this code should be running on the server at all.

Since this is a polyfill, it's intended use is for end users to add it to their application, not for individual elements to load and depend on it.

[jonathandewitt-dev]

So it's an issue of isomorphic code that can run on both server and client. When attempting to write a single definition for a web component that can SSR when no browser environment is detected, it becomes difficult to separate the static imports.

To be clear, I agree, individual elements should not use the polyfill. But the issue is that all web components should be imported alongside the polyfill. In theory, the component classes could be imported in two separate scripts (client and server) but that becomes burdensome. IMHO, it would be more ideal to just import the polyfill without worrying too much about its behavior on the server.

[justinfagnani]

I think what we want here if for the server DOM shim to just implement scored registries, like it implements the global registry today. We don't want to load the scoped registry polyfill, just like we didn't load the custom elements or shadow DOM polyfill. Individual components didn't load those polyfills either, and server code didn't because they definitely don't run on the server.

[jonathandewitt-dev]

Sure, and yeah that's all my pull request achieves, essentially. When imported on the server, with this change, it will simply ignore the polyfill rather than crash the script. If I'm understanding what you mean, that is.

[justinfagnani]

What I'm saying is that it should crash.

First, no one should be even trying to load this module on the server. The polyfill should be loaded by client-only app boot script that doesn't load on the server. Elements should definitely not be loading the polyfill themselves, they should leave it to the app.

Second, components that incorrectly do load the polyfill will not work anyway. They're going to crash at some other point when they attempt to use APIs that aren't there. Maybe those elements feature detect the old, non-standard scoped registry APIs, but then they would work without the polyfill and shouldn't load it since it's optional.

[jonathandewitt-dev]

I'm not sure I really understand why it would be beneficial to exclude client+server apps.

Maybe I'm not articulating clearly... the last time I tried a dynamic import with this polyfill, it did not work. I was unable to ascertain exactly why that was, at the time, but the point is it didn't work. So I'm not able to check for the window object myself and conditionally load this polyfill. It only works with a static import.

It sounds like you're envisioning a clear separation of server scripts and client scripts, but that would require either:

a. Some code-gen to automatically remove the import on the server only, or
b. Maintaining duplicate apps where one has the import and the other doesn't

Perhaps I'm missing a third option that could make it easy to separate these cases, but I'm not sure I'm understanding how preventing a crash could harm the polyfill or its consumers, where a warning in the console would suffice.

[jonathandewitt-dev]

What if this was exported as a module instead?

import { ScopedCustomElementRegistryPolyfill } from '@webcomponents/scoped-custom-element-registry';

// leave it to the consumer to load the script or not.
ScopedCustomElementRegistryPolyfill.load();

[jonathandewitt-dev]

Just to be extra clear, here is my use case. I wrote some scripts that will either render HTML on the server or upgrade custom elements on the client, automatically, depending on the environment.

import '@webcomponents/scoped-custom-element-registry';

import { MyButton } from './my-button';
import { MyCard } from './my-card';
import { MyInput } from './my-input';

MyButton.define('my-button');
MyCard.define('my-card');
MyInout.define('my-input');

First, this script runs on the server. The behavior of Element.define() adapts to a SERVER context and updates the HTML response by inserting the element's template between each instance of its tag.

Then, the same script runs on the client. The behavior of Element.define() adapts to a CLIENT context and runs native web component code to upgrade the elements in the DOM.

On the client, this polyfill is needed, so it must be imported. Since the same code also runs on the server, the polyfill crashes the script.

Hopefully the specifics of my problem are clearer with this.

[sorvell]

import '@webcomponents/scoped-custom-element-registry';

Right, this isn't the intended usage of the polyfill. Elements shouldn't import it since it changes the global environment. The containing page should import it. Then it should be relatively simple not to have it run on the server?

[jonathandewitt-dev]

import '@webcomponents/scoped-custom-element-registry';
Right, this isn't the intended usage of the polyfill. Elements shouldn't import it since it changes the global environment. The containing page should import it. Then it should be relatively simple not to have it run on the server?

I mean, again I agree, elements shouldn't import the polyfill. I guess I'm confused because the given code snippet is not an element, so I'm not sure how to respond to that.

All elements are imported and defined once, you could consider this snippet to be the containing page.