SSR

[WickyNilliams]

• Is SSR possible?
• If so, how?
• In what environments?
• Would need docs and examples

I tried @atomico/astro previously but hit some issues, and didn't want to go down that rabbit hole before release. Worth revisiting https://github.com/atomicojs/astro

[roeniss]

TL;DR: Will SSR be implemented soon?

Hi. I'm trying to introduce Cally to my project. The features and looks perfectly fit in.

Currently, the Cally Web Component is served as a HTML from my web server with script tag, meaning I have no React-like build process.

return `
...
<script type="module" src="https://unpkg.com/cally"></script>
<calendar-multi>
    <calendar-month></calendar-month>
</calendar-multi>
...
`

and the webpage shows sudden change before fully loaded:

I could reduce the time with make cally.js static file and use it, but I couldn't reduce it to zero.

I think it's impossible to make it zero until SSR implemented. If you have any idea to help, share it please :D

*edit: word

[WickyNilliams]

Right now SSR of web components is an unsolved problem. There are some specific solutions (like for Astro I mentioned in the original issue description), but there is no generic solution.

If you can stomach some layout shift you can avoid the small flash of an unstyled web component with this CSS:

:not(:defined) {
  visibility: hidden;
}

That will show the component only once it has been defined and upgraded.

There are potentially other options to improve this further, but that's generally a good starting point.

Let me know how you get on!

[roeniss]

Hi Wicky. For now, I will be satisfied with your solution!

Specifically, I applied the below style for my daisy@5-based app:

@layer utilities {
  calendar-multi:not(:defined) {
    visibility: hidden;
  }
}

[WickyNilliams]

Awesome! You can tweak it further with expected dimensions if you want to avoid layout shift as much as possible

[dgonzalezr]

Hello here 👋

I'm also trying to get cally to work with Next.js SSR. In my case, I have a components library implemented with Stencil.js and configured the stencil output target for SSR.

Before setting up SSR for the components library, I was bundling cally with the component by adding import cally at the top, which works as expected (with no SSR), but once I started to support SSR, this no longer works, which is also expected since cally rely on DOM API. So, I thought that maybe I could delay the import once the component is running on the client side, something like:

  async connectedCallback() {
    if (!isClient()) return;

    await import('cally');
  }

But still wasn't working as expected with Next.js, since the import gets hoisted.

Then I saw this issue and used the same workaround by injecting the library in the Document's head as a <script>,

  async connectedCallback() {
    if (!isClient() || isCallyLibraryLoaded()) return;

    try {
      await loadCallyLibrary();
    } catch (error) {
      console.error(error);
    }
  }

where loadCallyLibrary is a function that creates and appends the script to the document.head.

And this kinda works 😆 but I will be very interested in some more robust, future-proof solution if exists.
Is there any recommendation or a better approach I could use? Any plans to support SSR in the future?
Thank you so so much in advance 🙏

[WickyNilliams]

Why does the dynamic import() get hoisted? Is this a stencil thing or a next thing? Bizarre behaviour!

[WickyNilliams]

I wonder if I can do something with export conditions so at least it doesn't blow up in server environments. Maybe it should just be a stub module there. But I'm not sure how next bundles client Vs server code

Is marking this particular component as a client component viable or are you trying to avoid that?

[dgonzalezr]

Thank you @WickyNilliams for jumping in.

Why does the dynamic import() get hoisted? Is this a stencil thing or a next thing? Bizarre behaviour!

I think this happens because of how bundlers, like Webpack or Vite (which can be used by Next.js), handle dynamic imports during the build's static analysis phase. Even when using dynamic import(), these tools attempt to identify all potential imports at build time.

Is marking this particular component as a client component viable or are you trying to avoid that?

Well, with the stencil output target (which is like a plugin that allows you to ship specific framework packages for the same core library) all the components will use 'use client' when configured for SSR.

If I take this component out of the library, everything works as expected for SSR. I believe the issue relates to Cally being a web component that needs global registration through customElements.define(), which occurs when the script is loaded and executed (let me know if I'm mistaken). Therefore, with the whole components library, even if I do not use the date-picker component (which relies on Cally) in a Next.js project, that dynamic import will still be processed by Webpack and executed during SSR first, which is likely causing the problem.

[WickyNilliams]

Thanks for the info.

I'm familiar with stencil at least, having built a DS with it before (you might come across me in old issues at some point 😁)

I understand they will analyze the code and split the bundle at import() points. But that shouldn't mean hoisting that call to module level. If your import is conditional (as yours was) it's not a safe change.

I guess another option might be to add an entry point to cally which doesn't self register the component. That way you can control when it happens.

Another option might be to stub customElements.define() in your server app code somewhere. Like

globalThis.customElements ??= {
  define() {}
}

Is there any chance you could create a reduced test case with the combo of next/stencil/Cally? I understand that might be a bit of work, but it's much more likely I can dedicate time to it if I have a minimal reproduction of the issue!

[WickyNilliams]

Also, please could you add here the stack trace/exception that gets thrown when you encounter the issue (i.e. without any potential workarounds)

[dgonzalezr]

Is there any chance you could create a reduced test case with the combo of next/stencil/Cally? I understand that might be a bit of work, but it's much more likely I can dedicate time to it if I have a minimal reproduction of the issue!

Sure thing, I will set up a minimal repo with a stencil web component (that uses Cally) and a next.js minimal app that uses it.
I'll follow up here once I have it done 🙂

[WickyNilliams]

Appreciate it!

[hronro]

One approach might be useful for SSR is Declarative Shadow DOM, and it's support by all major browsers.

[SalahAdDin]

Is it possible?