Enhancing SSR Compatibility

[leventozen]

We've been utilizing a pattern for generating React components from our lit framework, aimed at encapsulating custom elements. This approach dynamically imports components using React.lazy and waits for the custom element definition using customElements.whenDefined. Here's a snippet for context:

const source = `
  ${jsDoc}
  export const ${componentName} = React.lazy(() =>
    customElements.whenDefined('${fileName}').then(() => ({
      default: createComponent({
        react: React,
        displayName: "${componentName}",
        tagName: "${fileName}",
        elementClass: customElements.get("${fileName}") as Constructor<${componentName}>,
        events: {
          ${eventNames}
        },
      })
    }))
  );
`;

While this pattern works well in client-side environments, we've encountered issues when integrating with server-side rendering (SSR) frameworks, such as Next.js. The reliance on customElements.whenDefined and dynamic imports via React.lazy poses challenges in SSR contexts, leading to rendering issues or failures when attempting to prerender these components.

[erbilnas]

Forward from #334 : We can use Lit's SSR support, but this is experimental and may cost us highly: https://lit.dev/docs/ssr/overview/