[SSR] accept a string for module contents when calling `renderModule` ("in memory" VM modules) #2086

thescientist13 · 2021-08-24T19:41:18Z

thescientist13
Aug 24, 2021

Overview

Not sure if this is feasible or just an over optimization, as I have just started playing around with the SSR package, but had a question / suggestion in regards to using VM modules and the renderModule function but was curious if there were other options for providing the "render" module other than as a file on disk? Say if you are generating a bunch of pages (like for a SSG) it could be cleaner and less steps if everything could be done "in memory".

Current Behavior

For example, from the docs, to render in a VM module, a file must be provided

// Example: render-template.js

import {render} from '@lit-labs/ssr/lib/render-lit-html.js';
import {myTemplate} from './my-template.js';
export const renderTemplate = (someData) => {
  return render(myTemplate(someData));
};

// Example: server.js:

import {renderModule} from 'lit-ssr/lib/render-module.js';

// Execute the above `renderTemplate` in a separate VM context with a minimal DOM shim
const ssrResult = await (renderModule(
  './render-template.js',  // Module to load in VM context
  import.meta.url,         // Referrer URL for module
  'renderTemplate',        // Function to call
  [{some: "data"}]         // Arguments to function
));

In the context of the the demo example, this seems reasonable if your app only has one template / layout. But it is common for (content heavy) apps and sites to have many layouts, for many types of pages. And with the need to be able to build pages on the fly for things like ISG or DPR, following this approach it would stand to reason that you would need a render-module.js type file for every possible page layout in your site.

A couple ways around this I could see, but feel a little clunky are:

Pre make all the needed and known render-module files for each known layout in the app, and then at render time have some sort of if / else or switch logic to choose the corresponding render module file for that given page / request.
Generate the file on the fly at build / serve time based on the page template and write it to disk, and then pass that new file path to renderModule (and presumably clean up these files following some sort of system?)

Both of these would have to maintained and kept up with over time, as templates come and go within the site.

Proposal

If there was the ability to just pass contents of render_module.js to renderModule function, then we could save a couple steps and perhaps be a little more ergonomic for these kinds of use cases, and probably tap into some optimizations / efficiencies too? 🙏

Something like this, where we

generate a string representation of that file, potentially leveraging whatever templating system may already exist in the system
Pass that to renderModule instead of a file path

// Example: server.js:

const renderModuleString = `
  import {render} from '@lit-labs/ssr/lib/render-lit-html.js';
  import {html} from '@lit';

  const htmlTemplate = (data) => {
    return html\`
      <html>
        <head>
          ${page.head.scripts}
          ${page.head.css}
        </head>
        <body>
         ${page.body.content}
        </body>
   </html>
  \`;

  export const renderTemplate = (someData) => {
    return render(htmlTemplate(someData));
  };
`;

const ssrResult = await (renderModule(
  renderModuleString,  // Module to load in VM context - accept a file or string?
  import.meta.url,         // Referrer URL for module
  'renderTemplate',        // Function to call
  [{some: "data"}]         // Arguments to function
));

kevinpschaaf · 2021-08-26T16:42:23Z

kevinpschaaf
Aug 26, 2021
Maintainer

Thanks for the feedback. The SSR API is indeed very raw right now, and we do intend to involve it to meet the use cases users bring up like this! We've been working hard to harden the core Lit 2 release, but once we get that out we'll start working more on refining the SSR API and testing it against user needs.

1 reply

thescientist13 Aug 26, 2021
Author

Thanks! Appreciate all the great work so far. 👌

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[SSR] accept a string for module contents when calling `renderModule` ("in memory" VM modules) #2086

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 1 comment 1 reply

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Select a reply

[SSR] accept a string for module contents when calling renderModule ("in memory" VM modules) #2086

thescientist13 Aug 24, 2021

Overview

Current Behavior

Proposal

Replies: 1 comment · 1 reply

kevinpschaaf Aug 26, 2021 Maintainer

thescientist13 Aug 26, 2021 Author

[SSR] accept a string for module contents when calling `renderModule` ("in memory" VM modules) #2086

thescientist13
Aug 24, 2021

Replies: 1 comment 1 reply

kevinpschaaf
Aug 26, 2021
Maintainer

thescientist13 Aug 26, 2021
Author