SSR + JavaScript without hydration

[digitalsadhu]

There are use cases where it would be nice to be able to SSR the podlet but not hydrate it but still include some script to be executed.

Eg Use Cases.

1. SSR the podlet, lazy load in tracking JavaScript or other scripts unrelated to the displayed podlet content.

2. SSR the podlet, its 99% non-interactive, so we manually add the JS to add some minor interactivity rather than hydrate simply because its much less byte expensive to this than to sent the whole component down the wire. (Finn header and footer both do this)

Should we add a file name convention and logic to support these?

One possible solution:

1. If a developer defines a file called scripts.js this file is then loaded into the dom AFTER the main script that hydrates or defines the podlet
2. If a developer defines a file called lazy.js, this file is loaded using dynamic import() after window load event has fired. A user can use this to load non critical path JS such as tracking scripts.

These files would typically be used in the following use cases like so:

• SSR + hydrate = content.js to define the component + lazy.js for tracking etc
• CSR = content.js to define the component + lazy.js for tracking etc
• SSR only = scripts.js as needed for interactivity + lazy.js for tracking etc

[trygve-lie]

My thought about this might be a little bit different. Currently Podium does run time composition by composing everything over http. Though I do see that there are some cases where that might not be the most optimal case. There are cases where a layout would benefit form pulling in a podlet as a plain NPM modules.

I do imagine that there is a mode where one use this setup to write a podlet in development mode. But, the module is published as a NPM package. What ever the consumer will then pull in this as a dependency as use it as a plain NPM module.

In the consumer end it would mean that one pull in a podlet as a dependency and somewhere the project one would need to import the module and use the web component tag. The consumer would then bundle up that podlet in the same way as it does with a plain NPM module since its just a plain NPM module.

So. I imagine that this service has a mode for writing a podlet which is intended to be published to NPM as the distribution instead of doing run time composition. That will imply that this module need to export some entry points in the NPM module.

Though; we might also want to do dynamic import of podlets as you describe.

My thought then is; what is the big difference between importing a podlet through NPM and dynamically importing it? Can we have a mode where a podlet is written so it covers that its either publised to NPM and consumed that way or pulled in through a dynamic import?

[digitalsadhu]

I think I see some different use cases here.

1. Build time composition, this might be podlet in podlet or otherwise and would require publishing to npm and probably backup of APIs served from the podlet. No content markup is served from the podlet though. Currently we don't have a proper answer to this use case yet but there is another issue covering an idea of how to solve it here: component-only Mode #17

2. Performance related lazy loading. This use case is mostly about getting script loading off the critical path. Dynamic imports are great for this. Tracking scripts are an example of when you might use this. Currently lazy.js serves this use case

3. Performance related "islands of interactivity" approach. This is not lazy loaded, but doesn't use hydration. You would server render your initial markup from the custom element but only layer on a thin layer of js on the client side to cover what you need. The header is a good example of this. There's very little you need to hydrate on the header but you do want to use your component library when building the server markup so you server render and then layer on some custom javascript on the client side to handle the cases "islands" that need it. Currently scripts.js serves this use case.