（一）SSR & SSG & CSR
SSR
Server-Side Rendering SSR (Server-Side Rendering) means that the html splicing process of the page is completed on the server side, and then sent to the browser, and the html structure that does not have interactive capabilities is bound to events and states, and displayed on the client side as having Application with full interactive capabilities.
SSR rendering process
Every time the page is refreshed, it will reach the server, obtain remote data from the server, and then render a static page with the data and return it to the front end.
Taking the cds project we developed as an example, the list of menu items on the left is requested on the server side, and then the data and page structure are spliced together and returned to the front end, so the returned page contains list data.
Advantages of SSR for SEO
Search engines rely on crawlers. The process of a crawler crawling an Internet page is to get the response result according to the request page link, register the response result, register the content tags in it, etc., and store these as the results of the crawler. When a user searches for the corresponding When searching for keywords, he went through some searches and recommended the results. However, search engine crawlers will not wait for the end of the asynchronous request data before grabbing information.
If it is a CSR page, it will not render the data after it is acquired, but just return an empty shell without returning data. So this is not friendly to search engines, and it cannot capture key information. The HTML document returned by CSR for the first time is an empty node (root) and does not contain content. The crawler cannot analyze the content of your website, so it cannot give you a good ranking.
The advantage of SSR lies in synchronization. The data is taken in advance on the server side. The data and pages are assembled on the server side, and the static pages are spit out to the front end. The styles are then loaded with css through links and other forms. To put it another way, when the SSR page is linked, the backend spells out the data, without asynchronous requests, the structure and content are all there, and the frontend needs to request additional style files. SSR returns the rendered HTML fragment with complete content, so it can be better analyzed and indexed by crawlers. At the same time, the time for users to see the page is shortened a lot.
SSR has faster first screen loading speed
There is no need to wait for the JavaScript to finish downloading and executing before displaying the content. You can see the fully rendered page faster and have a better user experience.
The SSR server is only responsible for the first rendering
The server is only responsible for the first "rendering" (in a real sense, only the browser can render the page, the server actually generates HTML content), and then returns to the client, the client takes over the page interaction (logic such as event binding), and then the client When the end-to-end route is switched, the corresponding content is displayed directly through the JS code, and server-side rendering is no longer required (only when the page is refreshed)
SSG
Generally used on official websites. For pages with less dynamic data.
In the stage of code compilation, this page is generated, and the page is directly proxied. It will return the same thing to you for countless visits. It is suitable for unchanged pages and does not need to go through the server-side pages.
CSR
client rendering
CSR rendering process
The CSR experience is not very good. First you see a blank page, then load js, and return an empty shell, and the crawler only crawls to the empty shell.
(2) The principle of realizing SSR
SSR refers to the process of rendering a single-page application (SPA) into an HTML fragment on the server side, sending it to the browser, and then handing it over to the browser to bind state and events to it, and become a fully interactive page.
The core of the SSR principle - isomorphism
The so-called isomorphism, in layman's terms, means that a set of React code runs once on the server, and runs again when it arrives at the browser. The server-side rendering completes the page structure, and the client-side rendering binds events
Implementation process of SSR principle isomorphism
Server-side execution process: Use renderToString under react-dom/server on the server side to convert the React component into a string, splice it in html and return it. At this time, the html does not contain the event corresponding to the element. When packaging, package the logic of hydrate under react-dom into js, splice it in html and return it as a script tag, and provide it to the client to run and use the browser to execute the process: request html,
render the page content returned by html and download the js file, At this time, the page displays elements but cannot be interacted with. Run ReactDom.hydrate in js to bind events to the page elements, and the page can be interacted with.
Water injection and dehydration of data and its realization principle
Water injection and dehydration of data: water injection refers to the data transfer to the client after the server requests data, and dehydration is the process of using data by the client.
Server-side execution process: The server obtains the matching routing object according to the page path in the request request, puts the static method loadData mounted on the routing object in the promise and executes it uniformly, and injects the request data into the html script
tag (by mounting the data under window.context) and return to the client.
Client execution process: request html, receive html with data, and render the page with server-side data. run
<script>window.context...</script>
, download and run the index.js file, the js code will directly use the window.context to initialize the initialState, so as to ensure that the page calculated by the client for the first time is exactly the same as the html returned by the server.
Implement the project address of the SSR framework
Project address: https://github.com/yjdjiayou/react-ssr-demo
(3) Precautions for using Next.js (SSR framework)
1. Use the front-end proxy to report an error 404 problem & use route mapping to report an error 404 problem
(1) Use route mapping to solve the problem of error 404 caused by erasing the front-end proxy prefix due to front-end route switching
When developing a CDS project, click the link in the side navigation bar to jump to the system configuration application. The system configuration application is an independent application, not a micro-frontend sub-application of the CDS project, but we hope that after the CDS project jumps to the system configuration application, the address bar The address shown is that of the CDS project.
So according to this requirement, we configure the proxy, and we configure the request proxy starting with /admin to go to the system configuration application.
So our address bar becomes as follows:
Home page: https://delivery-admin.fast-inside.tuya-inc.cn:7799/admin
isv customer page: https://delivery-admin.fast-inside. tuya-inc.cn:7799/admin/system/isv-client
There is no problem with the address bar as above, and the page can be displayed normally even when the page is refreshed.
But in the system configuration project, if we click the link tag, it will replace the content after orgin with the href attribute value, that is to say, erase /admin. As follows, we switch from the home page to the isv-client page by clicking the link label. There is no /admin in the address bar. Although it can be displayed normally, after we refresh the page, because the main CDS application does not configure /system-related agents, it itself does not There is no corresponding routing page, so a 404 error is reported.
So we hope that our front-end routing switch can have a prefix like /admin, then we can use route mapping to set the as attribute with /admin for the link tag, so that the origin of the address bar will be displayed as the as attribute value, In this way, there is /admin in the address bar, which solves the problem of error 404 reported after the CDS main application jumps to the system configuration item and refreshes the page.
(2) Use the front-end agent to solve the problem of route mapping error 404 under independent deployment
Continuing with the question in (1), after we configured the route mapping, we deployed the system configuration items independently, and found that an error 404 would be reported as soon as the page was refreshed. Why? Because when we click the button to jump on the browser side, because it is a SPA application, the front end changes the browser route without refreshing the page. It is the browser to find the page, which can be found through route mapping. When refreshing, the server is looking for it, and there is no /admin/xxx file in our pages page, so 404 is reported.
Solution:
Method 1: use the Node framework (koa) to replace the default server that comes with Next.js, and return the /xxx page to the request for /admin/xxx.
Method 2:
1. In the production environment, configure the proxy on the libra publishing platform, and proxy the request of /admin to this project.
2. In the development environment, under the next framework of tuya, configure the proxy attribute under the base node in the config/index file.
2. Server execution order
1._app getInitialProps()
2.page getInitialProps()
3._document getInitialProps()
4._app constructor()
5._app render()
6.page constructor()
7.page render()
8._document constructor()
9._document render()
3. Client execution sequence (opening the page for the first time)
1._app constructor()
2._app render()
3.page constructor()
4.page render()
Note: When the page is initially loaded, getInitialProps will only be called on the server side. Only when the route jumps (Link component jumps or API method jumps), the client will execute getInitialProps.
4. Routing jump execution order
1._app getInitialProps()
2.page getInitialProps()
3._app render()
4.page constructor()
5.page render()
reference article
https://segmentfault.com/a/1190000041170750