CODEWITHSUNDEEP
reactjsnext.jssingle-page-applicationserver-side-renderingclient-side-rendering
han
han

Reputation: 97

How single-page application works in SSR (React)

From what I gathered, SSR means that when there is '/' http request for example, your server gets the request and starts collecting every rendable piece such as jsx codes. Then your server renders it to 'index.html' page. After your index.html gets ready and it is shipped to the browser, so in the first-load phase, the browser can get the HTML markup packed with actual contents and all it needs to do is just reading HTML and displaying it!

Am I correct?

Then, for example, we have another page 'about.html'. What is gonna happen in our SSR server?

  1. When the user entered the "/about" page (not from navigating, just entering the URL). Then your server renders 'about.html'? If that's the case, isn't it multiple page application because the server actually renders multiple pages on each URL request?

  2. Otherwise, the server still renders '/index.html' including all of those dependencies regarding SPA and sends it to the client, and the browser handles it and renders '/about' page again? It doesn't make sense to me because the search engine can't read 'about' info from the first-load anyways as the loaded HTML is all about 'index' info and there are no contents about 'about' yet until the user navigates to '/about'. It sounds like client-side rendering to me.

I don't even know what I need to search or learn more about. Can you guys give me some hints?

Upvotes: 1

Views: 1638

Answers (1)

Naor
Naor

Reputation: 24053

When implementing Server Side Rendering (SSR), the server knows how to generate a full page with markup so the user gets a fully rendered page and from that moment, when the js resources get downloaded, the application will be live (event listeners will be enabled, the react lifecycle will be active and so on).
Suppose you have App component that is an entry point for you app, a general SSR implementation will:

  1. Get a request for a specific path
  2. Initiate a new store instance for the request
  3. In case of using react router (or other router solution), fill the state with the requested route
  4. Render the app, but instead of rendering and mounting the App, render the App to string (with renderToString)
  5. Dehydrate the state - take the latest state snapshot and append it to the result (after escaping it and wrapping it with script tag for example)
  6. Return the markup as a response. The markup can look similar to the following:
<html>
...
...
<body>
    ...
    <App markup>
    ...
    <script><window.state = {state snapshot}></script>
</body>
</html>
  1. The browser gets the html and renders it (before react), so the user already have something on the screen
  2. The browser downloads the app bundle
  3. The app bundle includes the App that initiate the state with the provided state snapshot (Rehydrate)
  4. The App rendered into the DOM, if done correctly, no actual DOM rendering should happen since the result will be the same (app rendered according the same state as it was rendered in the server)
  5. From this point the app behaves regular. Any route change doesn't trigger the SSR engine

There are several frameworks (next.js for example) that comes out of the box with SSR solution along with code splitting according to routes. So when the user change route, a new backend request triggers the SSR flow again for the new route.
SSR can be implemented in many different variations, but the basic stays the smame

Hope this gives a good starting point for understanding SSR.

Upvotes: 5

Related Questions