Prerendering!

[developit]

This adds prerendering, via a new loader I created called prerender-loader.

It also cleans the webpack config and app code up a bit to keep eslint and Node happy.

[jakearchibald]

@developit Can you talk a little at a high level about what this is trying to do & how it's going about achieving it? I'm struggling to get my head around it.

[developit]

Yup! It's definitely a bit thick. The basic premise is this:

1. html-webpack-plugin expects an HTML template, into which it injects Webpack's output resources.
2. Normally people use a loader like ejs-loader to preprocess the HTML template and insert things like preload chunks.
3. We can create a new loader that actually renders our existing application to an HTML string, and use that in place of a static HTML template.
4. To do this, we need a slightly tailored bundle that is built to run under Node rather than in a browser. Thankfully, Webpack provides a way to spawn a lightweight "sub-compiler".
5. The "sub-compiler" builds quickly because it has no plugins and outputs to an in-memory filesystem.
6. The resulting transpiled+bundled CommonJS code is invoked inside JSDOM to capture any DOM side-effects (inserted meta tags, document.title, etc)
7. The output is captured
   a. If the entry module exports a value, that value is resolved (function called, promises awaited)
   b. If the resolved value is a String, it is taken to be the prerendered HTML content.
   c. If there is no export or its resolved value is null / undefined, the document is serialized in its entirety and used as the prerendered HTML.
8. The HTML String from step 7 is then consumed by html-webpack-plugin as if it were a static template

[jakearchibald]

We can create a new loader that actually renders our existing application to an HTML string, and use that in place of a static HTML template.

Why is this better than creating an HTML string that we include in an ejs template?

The resulting transpiled+bundled CommonJS code is invoked inside JSDOM to capture any DOM side-effects (inserted meta tags, document.title, etc)

Wouldn't it be easier to just author this in ejs?

[developit]

It's automatic. Otherwise yes, grabbing a snapshot of the DOM from Chrome would work fine too. Just now you need to keep the two in sync.

Also worth noting - CSS Modules auto-generates hashed classNames, which means the HTML here varies any time you touch a file. It would be very tedious to manually all that in sync.

[jakearchibald]

It's automatic. Otherwise yes, grabbing a snapshot of the DOM from Chrome would work fine too. Just now you need to keep the two in sync.

I'm not suggesting that we copy & paste like that. I'm trying to figure out what this gives us over rendering the app to a string (using preact-render-to-string), and feeding that to the template.

[developit]

Ah - this allows that. In order to get to the point where you can render-to-string, you need a bundle that will run in Node (no TS, JSX, etc) - this just creates a small child compiler to produce exactly that.

Here's what src/index.ts looks like if you want to use preact-render-to-string:

import renderToString from 'preact-render-to-string';
// etc


export default () => {
  return renderToString(<App />);
}

The JSDOM trappings are simply to avoid a bunch of pitfalls of running in an environment with no DOM. If the app doesn't use document, it doesn't do anything.

[developit]

[jakearchibald]

Does this give us a way to detect if our app is being rendered as part of a prerender, and omit/alter components accordingly?

[developit]

Yup! That's the best part, and one of the main reasons this requires a child compiler instance. It inlines PRERENDER=true for the bundle the runs under Node, and PRERENDER=false for the client bundle. Like with env vars, uglify will dead-code-eliminate if (PRERENDER) { } blocks entirely from the client bundle.

In other similar setups, I've used this to do synchronous work during prerendering and then serialized cached values derived from that work in a <script> tag that gets picked up by the client to avoid render-blocking network requests. Here's an example that uses this technique to make use of a Worker only on the client.

[developit]

ToDo:

• remove as many isProd as possible (uglify, etc)
• move out prerender-loader, switch to dep, disable import for now

[ebidel]

Half trolling but....

Have you all considered using headless chrome to prerender pages?
https://developers.google.com/web/tools/puppeteer/articles/ssr#tldr

Asked another way, is anyone but @developit going to be able to maintain this? :)

[jakearchibald]

Headless Chrome could replace the JS DOM part, but not much else. It'd still be complicated.

[developit]

Yup yup - we discussed it a few times. In this case I think we'd actually rather remove JSDOM by default. Right now it's mainly being used to compress and normalize the String render.

You should see the other plugin I'm building if you think this one is a little crazy haha

[ebidel]

Haha. Ping me if you have questions or need PPTR help!

#realDOMforLife

[developit]

Alright @jakearchibald @surma - all prerendering & critical stuff has been removed for now.

[jakearchibald]

This is redundant, right?

[developit]

Ah yeah, I'll remove it.