-
-
Notifications
You must be signed in to change notification settings - Fork 376
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Experimental Fast renderer #1482
Comments
This was referenced Dec 8, 2020
Unfortunately the experimental renderer never did make it in, but if someone still needs fast prerender.js script: |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: