State of the project

Does someone else want to take this idea and run with it? I would be 100% happy to not be the maintainer of this project 😃

What are your current plans? I’m asking because there is react-snap, which is a tool inspired by react-snapshot, but uses puppeteer. Because it uses puppeteer it does not have most of the bugs currently opened in react-snapshot.

Related https://github.com/peterbe/minimalcss/issues/23

[geelen]

Hey! Thanks for taking this idea and running with it. I have been really lacking in time to maintain this project, but I really love this idea.

I’ve basically gone back to the drawing board to think about how this could work in a React16+ environment with async data requirements, even to the point of doing on-demand snapshots as an alternative to SSR, all of which has lead me to wonder what the correct direction to take is.

Perhaps we should have a chat about combining our efforts. I’m much interested in potential React-specific optimisations, perhaps I could be building on top of react-snap instead of competing with it…

[stereobooster]

react-snap vs react-snapshot

react-snapshot uses jsdom so it supports only limited browser API(1), on the other side jsdom is more lightweight than a real browser e.g. chrome (puppeteer). A real browser uses more memory, CPU (?), network(2), uses a separate process which introduces additional overhead (?) and npm package much heavier - it downloads chrome binary (3).

(1) we can expose callback before page evaluated, so a user can provide polyfills https://github.com/geelen/react-snapshot/issues/93 (2) this can be fixed by blocking some network requests (3) this step can be skipped, but this is not supported by react-snap as of now

jsdom limitations

Examples: https://github.com/geelen/react-snapshot/issues/93, https://github.com/geelen/react-snapshot/issues/85, https://github.com/geelen/react-snapshot/issues/50, https://github.com/geelen/react-snapshot/issues/40, https://github.com/geelen/react-snapshot/issues/33, https://github.com/ant-design/ant-design/issues/7341

Async snapshots

See https://github.com/geelen/react-snapshot/pull/30. I believe there are two good approaches here:

networkidle

This is what react-snap uses. This technique is proved to be powerful enough to work in many cases without additional configuration. This is built-in puppeteer functionality - consider navigation to be finished when there are no more than 0 network connections for at least 500 ms.

Theoretically, it is possible to implement it for react-snapshot.

renderComplete

This idea was taken from Rendertron. The first call to renderComplete will disable default mechanism e.g. networkidle and prerenderer will start to wait for the second signal. It will be up to the user to implement when to call this function. Related: react#1739, react-transmit

Other limitations

React

react-snapshot is limited to React only projects. react-snap is framework agnostic

Critical CSS

react-snap can inline critical CSS. It is possible to do this in react-snapshot because the core of minimalcss (which is used by react-snap) based on cheerio and csstree.

webpack code splitting

Currently, create-react-app configured webpack code splitting doesn’t work with prerenderes out of the box. Need to implement a fix for it. Or change c-r-a to use chunksSortMode: 'dependency'

other performance optimizations

I believe it will be possible to replicate those in react-snapshot.

ReactDOMServer

Current implementation of react-snapshot brings ReactDOMServer to the client. See https://github.com/geelen/react-snapshot/pull/91

Difference in conventions

• react-snap generates /a/b/index.html for both /a/b and /a/b/. I believe this is less confusing
• react-snap generates /404.html if there is more than one page
• react-snap does not have ignore option
• react-snap exposes snapSaveState callback to be able to save a state of Redux, async components etc.

Maybe there are other small differences which I forgot

conclusion

I believe there is a niche for jsdom based prerenderer, but it needs more work. If we decide to continue work on jsdom based prerenderer it would be nice to use same conventions so two tools can be swaped without additional work