You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently pre-rendering is handled by HTMLWebpackPlugin and webpack. This is quite memory expensive and works on main thread. On a few random tests the preact build command simply crashes when asked to create a build with 500-1000 pages and some sizable amount of pre-render data.
Even in the scenario where it does not crash it takes quite a long time to finish the build, sometimes even 30 minutes or more. See #1463 .
What is the expected behaviour?
Pre-rendering should not be this memory expansive and should finish much much early on. See gatsby/next and others for inspiration.
We can probably move pre-rendering out of the webpack toolchain and use nodejs worker threads to pre-render the pages in parallel. The new rendering will have a set API for the ejs templates which can be guarded with SEMVER. All pages can pre-render in their own worker threads and the files can be written at the end.
We can start with an experimental option in V3 and land it as stable in V4.
e.g. preact build --experimental-fast-render.
The API for the ejs templates would be as follows.
{options: {webpack: {public_path: '...',assets: [...],//list of all assets generated by webpack},data: {url: '...',title: '...'.CLI_DATA: {},// all the pre-render data for this route}}}
We would also morph this data to slightly match the HTMLWebpackPlugin's existing schema so that if anybody is trying to use this option without much change in template.html then they would be able to.
Path to SSR
Since re-building will no more be a requirement for pre-rendering, we can extend this to on-request rendering/ SSR. We can expose a module from preact-cli which can consume a given build and pre-render a route with a given data/props and return an SSRed string.
e.g.
// in an express serverconst{Prerender}=require('preact-cli');
...
constrenderer=newPrerender({buildDirector: '../build'})app.get('/product/:pid',req=>{res.send(renderer.render(`/product/${req.query['pid']}`))});
The text was updated successfully, but these errors were encountered:
Do you want to request a feature or report a bug?
RFC
What is the current behaviour?
Currently pre-rendering is handled by
HTMLWebpackPlugin
andwebpack
. This is quite memory expensive and works on main thread. On a few random tests thepreact build
command simply crashes when asked to create a build with 500-1000 pages and some sizable amount of pre-render data.Even in the scenario where it does not crash it takes quite a long time to finish the build, sometimes even 30 minutes or more. See #1463 .
What is the expected behaviour?
Pre-rendering should not be this memory expansive and should finish much much early on. See gatsby/next and others for inspiration.
We can probably move pre-rendering out of the webpack toolchain and use nodejs worker threads to pre-render the pages in parallel. The new rendering will have a set API for the
ejs
templates which can be guarded with SEMVER. All pages can pre-render in their own worker threads and the files can be written at the end.We can start with an experimental option in V3 and land it as stable in V4.
e.g.
preact build --experimental-fast-render
.The API for the
ejs
templates would be as follows.We would also morph this data to slightly match the
HTMLWebpackPlugin
's existing schema so that if anybody is trying to use this option without much change intemplate.html
then they would be able to.Path to SSR
Since re-building will no more be a requirement for pre-rendering, we can extend this to on-request rendering/ SSR. We can expose a module from
preact-cli
which can consume a given build and pre-render a route with a given data/props and return an SSRed string.e.g.
The text was updated successfully, but these errors were encountered: