some questions related:)

[begoat]

Firstly thank you for this repository, which enables us to write code once and enjoy isomorphic application easily.
I have several questions to ask and need someone to communicate with so that I will not struggle at some knowledge pieces.

1. I use window object which doesn't exist in server side in my code, it be ignored while compiling, right? And what if I use requestAnimationFrame or setTimer in my code, will it leads to memory leak? or It can be refined by webpack config target: node.

2. How can I do client side rendering for specific route? By setting router separately in the express server ? for example not to use app.get('/*'),use app.get('/login') if I want login page can do client side rendering?

3. how can I do client side rendering fallback when the traffic is too busy?

Thanks in advance. I am newbie and just some clews is also ok.

[jariz]

1. I wouldn't go for automatically removing window calls, that would lead to rather unexpected code.
   You are personally (now) aware that window calls do not work on SSR, but your team mates might not, and they'll be wondering why it's silently removing their code ;)
   Therefore it's good that they'll get an error, it just means you're supposed to check if window is actually available before calling a function on it.
   I always just do a quick check a la typeof window !== 'undefined', if you want to make this more autological you could even put it in a export as thus

export const isServer = typeof window !== 'undefined'

Node is already being targeted on the serverside.
setInterval / setTimeout will work regardless of platform. requestAnimationFrame is browser only.
Memory leaks in JS generally are fairly hard to create, but should be something to note, sure.
Don't just blindly push to an global array everytime your setInterval function gets called (or whatever, but this example also applies to the browser...).

2. The default template includes react router, so no need for manually defining a route on the serverside, the appropriate route will be rendered from both the server as clientside.

3. Cool question. I've done this before myself, but sadly it's not that simple.
   What you'll have to do is create a sitemap that requests all pages available, either through fetch or just by calling react-router's match for each page you have available.
   Then you will need a static webserver like apache or nginx to serve up those generated HTML files.
   Do keep in mind that stuff like POST'ing and query parameters will not work anymore or result in differences between SSR and CSR output.

[begoat]

@jariz Thank you for the reply :) I think I didn't fully understand the answer to the second question.

For example, I have an app using razzle with react-router, and in the app I have three routes pointing to three components.

My current understanding is that when I make a request to url http://localhost:3000/first, the entire app will be renderedToString, and send to the client. how can I only let localhost:3000/second do client side rendering ??

[jariz]

I guess you could theoretically make a new route (before the catch all * route), that just serves the bundle and has a empty root tag.
You'd have to serve a bundle that has a different entry point though, because the current entry point calls hydrate, which assumes the HTML is already initialized.
Do not change hydrate to render because this is a really bad for performance in cases where you are doing SSR. (it is also deprecated and will be removed in react 17)

But yea, just because you can, doesn't mean you should.
You'd lose all benefits of server side because there would be a slower initial page load, and you already have the entire SSR setup ready, so why only partially implement it?
The choice is up to you ofcourse, I'm just wondering what the motivation behind this could be.

[jariz]

Also, if things get busy, disabling SSR won't really have all that much of a difference imo.
It is rather fast, especially now with React 16, and if you're already serving all your stuff through express, rendering your react app as well won't really make that much of a difference performance wise.
I don't really have the numbers to proof it (blog post idea!), but that's been my personal experience working with a rather large website that went down a couple times, in the end always turning out that SSR wasn't the culprit.

[begoat]

Yes, I think you are right. In my project I use react-loadable to do code-splitting and lazy load. Though I didn't apply some cache strategy and the performance is not bad I think.

And the motivation is that I read some blogs mentioned this idea partially server side rendering. And I just want to have a try. I wonder how can I do that in this project. Now I will not do that because no need:)

And I will learn more about question3 if I am available, thank you for your answer and thank you all your guys for this awesome repository:)

[jariz]

👍

[qramilq]

@jariz Do you have any blog post about question #3? Or do you at least know how to detect when we need to do client side rendering fallback?