State of the project

[stereobooster]

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 peterbe/minimalcss#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]

Perhaps we should have a chat about combining our efforts.

Would be glad to collaborate with someone

I'm much interested in potential React-specific optimisations

I use react-snap for the create-react-app based project, so it is kind of assumes React. Interested what do you have on mind

[geelen]

What timezone are you in? We could try to arrange a call, or at least a chat. I’m in Melbourne GMT+11

[stereobooster]

I'm in Berlin GMT+2

…

On Tue, Nov 14, 2017 at 10:19 PM, Glen Maddern ***@***.***> wrote: What timezone are you in? We could try to arrange a call, or at least a chat. I’m in Melbourne GMT+11 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#80 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAK9TqcXJDhPpDUDXvk97HpwF9TU8eJQks5s2gPNgaJpZM4QEVr6> .

[stereobooster]

So as of optimisation of react. Take a look https://github.com/stereobooster/an-almost-static-stack there are all kinds of optimisations. Especially check fetch example. Do you a see way to improve it?

[stereobooster]

I'm much interested in potential React-specific optimisations

I found what those could be:

• saving state of redux store Add snapshotState for any JSON serializable data #46
• fix flash with code splitting and react-loadable Find loadable solutions which works with snapshots without redraws stereobooster/react-snap#46

[stereobooster]

Actually I was able to fix all issues. I have no example of project, that react-snap can not handle. It has a lot of React relative optimisations, like async components support and Redux support. I will close this issue for now. Thanks

[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 #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: #93, #85, #50, #40, #33, ant-design/ant-design#7341

Async snapshots

See #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 #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