Non browser environments

[ericponto]

We would like to include this polyfill with our Lit components we are building that use element internals. This makes it very easy for consumers of the component to have a single import and not have to worry about polyfilling. However, we import these components in a server-side rendering setup and this polyfill runs and tries to instantiate a new MutationObserver, which causes it to break.

We'd really like to not have to separate the import of the component from the import of the polyfill.

I'd be willing to submit a PR to address this, but would like feedback on posssible solutions.

• wrap instantiation of the polyfill with a browser check (maybe just typeof window !== "undefined")
• provide a version of the polfyill that doesn't auto-initialize and allows users to manually call a function to initialize it
• use the exports field in the package.json to point to a different noop version for node vs. the default

[calebdwilliams]

I’ve been thinking about this as well. I’m not sure what the best approach is to be honest. I actually had it on my radar to dive into both Lit’s SSR and Astro today. Let me mess around with it a bit and see if I can come up with an approach that feels good.

I’d also be happy to chat here about it or field a PR but don’t want to just accept the first possible solution.

[calebdwilliams]

I added a PR to Lit's @lit-labs/ssr-dom-shim. This is at least a start. Once that's in I think there's a couple things we can look at but just capturing for posterity: lit/lit#3677

[calebdwilliams]

@ericponto are you using the @lit-labs/ssr utility to server render your components? And/or are you using any of the ARIAMixin properties in ElementInternals? The PR linked above should enable not only internals on the server but also render elements with the proper ARIA tags as well.

I'm not sure about other environments, but I'm hoping that support for internals can be added to those environments longer term to ensure proper ARIA mechanics.

[ericponto]

We are using @lit-labs/react and then doing SSR with Next.js. So it isn't rending the shadow dom or anything server side, just the outer WC tags and their attributes.

[calebdwilliams]

Got it. Well, the above PR will solve this issue, given the following input

customElements.define('lit-internals', class extend LitElement {
  constructor() {
    super();
    const internals = this.attachInternals();
    internals.role = 'widget';
  }

  render() {
    return html`<h1>Hello <slot>world</slot></h1>`;
});

and

<lit-internals>y'all</lit-internals>

it will output the following before hydration

<lit-internals role="widget">
  <template shadowroot="open">
    <h1>Hello <slot>world</slot></h1>
  </template>
  y'all
</lit-internals>

I'll leave this issue open until Lit's SSR package either accepts my (or a similar PR) or decides they don't want to support this use case and I can write alternative documentation here.

[hrmcdonald]

We have run into a similar issue with this polyfill around HTMLFormElement is not defined during Lit SSR in Astro. Would the Lit PR address that issue as well?

[calebdwilliams]

I don’t think it would. I can take a stab at cleaning some of that up.

Good call out.

[calebdwilliams]

OK, 1.2.6 will check if HTMLFormElement exists before attempting to patch it. I can probably write some more here to make sure everything will work. I might just see if I can come up with a better way to do a lot of this work on the server.

At the very least I'd like attribute hydration for the ARIAMixin stuff and no errors thrown :D

[hrmcdonald]

Also seeming to run into the following with the latest version of the polyfill loading Lit in Next.js:

ReferenceError: MutationObserver is not defined

Not sure if that is something you'd expect Lit SSR shim to handle though? I can open an issue over there if so.

[calebdwilliams]

Ideally none of the polyfill should run on the server. I just don’t know a reliable way to check if the polyfill should run.

[hrmcdonald]

Ah I see, could you potentially expose an entry point that isn't an IIFE? So for example in Lit projects, the polyfill could be conditionally initialized after checking the isServer variable.

EDIT: I guess this would still potentially cause compilation failures.

[calebdwilliams]

This should work in element-internals-polyfill@1.3.0