SSR开发详解

（一）SSR & SSG & CSR

SSR

服务端渲染 SSR (Server-Side Rendering)，是指在服务端完成页面的html 拼接处理， 然后再发送给浏览器，将不具有交互能力的html结构绑定事件和状态，在客户端展示为具有完整交互能力的应用程序。

SSR渲染流程

每次刷新页面的时候都会达到服务端，从服务端获取远程的数据，然后渲染带有该数据的静态页面返回给前端。

以我们开发的cds项目为例，左边菜单项列表是在服务端请求完成的，然后将数据和页面结构拼接起来后返回给前端，所以返回的页面里是有列表数据的。

SSR在SEO方面的优势

搜索引擎依靠的是爬虫。爬虫爬取互联网页面的流程是，根据这个请求页面链接，拿到响应结果，对响应的结果进行登记，登记里面的内容标签等，把这些作为爬虫的结果存取起来，当有用户搜索相应的关键词的时候，他经过一些查找，把这些结果推荐出去。但是搜索引擎爬虫是不会等待异步请求数据结束后再抓取信息的。

如果是CSR的页面，它不会把数据获取好后渲染出来，只是返回空壳子架子，不会返回数据。所以这样对搜索引擎不友好，它抓取不到关键信息。CSR 首次返回的 HTML 文档中，是空节点（root），不包含内容，爬虫就无法分析你的网站有什么内容，所以就无法给你好的排名。
SSR的优势在于同步，在服务端提前把数据拿好了，数据和页面是在服务端就拼装好了，吐给前端就是静态页面，样式后续通过link等形式加载css。换种方式来说，SSR页面链接过来的时候，后端把数据拼好，少了异步请求，结构和内容都有了，前端这边就是需要额外请求样式文件。SSR 返回渲染之后的 HTML 片段，内容完整，所以能更好地被爬虫分析与索引。同时用户看到页面的时间就缩短了很多。

SSR有更快的首屏加载速度

无需等待 JavaScript 完成下载且执行才显示内容，更快速地看到完整渲染的页面，有更好的用户体验。

SSR服务端只负责首次渲染

服务端只负责首次“渲染”（真正意义上，只有浏览器才能渲染页面，服务端其实是生成 HTML 内容），然后返回给客户端，客户端接管页面交互（事件绑定等逻辑），之后客户端路由切换时，直接通过 JS 代码来显示对应的内容，不再需要服务端渲染（只有页面刷新时会需要）

SSG

一般用于官网。用于动态数据少的页面。
代码编译的阶段就把这个页面生成好了，直接把这个页面代理出去，无数次访问它都给你返回一样的东西，它适合不变的页面,不需要经过服务端的页面。

CSR

客户端渲染

CSR的渲染流程

CSR体验不太好，先看到空白页面，然后加载js，返回的是空壳子，爬虫就只爬到空壳子。

（二）实现SSR的原理

SSR是指将单页应用（SPA）在服务器端渲染成 HTML 片段，发送到浏览器，然后交由浏览器为其绑定状态与事件，成为完全可交互页面的过程。

SSR原理的核心-同构

所谓同构，通俗的讲，就是一套 React 代码在服务器上运行一遍，到达浏览器又运行一遍。 服务端渲染完成页面结构，客户端渲染绑定事件

SSR原理同构的实现流程

服务端执行流程：在服务端使用react-dom/server下的renderToString将React组件转化为string，拼接在html中进行返回。此时html中不包含元素对应的事件。打包时把react-dom下的hydrate的逻辑打包到js中，拼接在html中作为script标签返回，提供给客户端运行使用
浏览器执行流程：请求html，渲染html返回的页面内容并下载js文件，此时页面显示元素但不可交互，运行js中的ReactDom.hydrate给页面元素绑定事件，页面可交互。

数据的注水与脱水及其实现原理

数据的注水与脱水：注水指的是服务端请求数据后，将数据传递给客户端，脱水就是客户端使用数据的过程。
服务端执行流程：服务端根据request请求中的页面path，获取匹配到的路由对象，将路由对象上挂载的静态方法loadData放在promise中统一执行后，并将请求数据注入到html的
script标签中(通过把数据挂载在window.context下），返回给客户端。
客户端执行流程：请求html，收到带有数据的html，渲染带有服务端数据的页面。运行

<script>window.context...</script>

，下载并运行index.js文件,js代码中会直接取用window.context初始化initialState，从而保证客户端首次计算出的页面与服务端返回的html完全一致。

实现SSR框架的项目地址

项目地址：https://github.com/yjdjiayou/react-ssr-demo

（三）使用Next.js (SSR框架)的注意事项

1.使用前端代理报错404问题&使用路由映射报错404问题

（1）用路由映射解决因前端路由切换抹掉前端代理前缀导致报错404的问题

在开发CDS项目中，点击侧边导航栏链接跳转系统配置应用，系统配置应用是一个独立的应用，不是CDS项目的微前端子应用，但是我们希望CDS项目跳转系统配置应用后，地址栏显示的地址是CDS项目的地址。
所以根据这个要求，我们配置了代理，我们配置/admin开头的请求代理去系统配置应用。
所以我们的地址栏就成了如下这样：
首页： https://delivery-admin.fast-inside.tuya-inc.cn:7799/admin
isv客户页面： https://delivery-admin.fast-inside.tuya-inc.cn:7799/admin/system/isv-client
如上这样的地址栏是没有问题的，刷新页面也都能正常的显示页面。
但是在系统配置项目这里我们点击link标签，它会将orgin后面的内容替换成href属性值，也就是说把/admin给抹掉了。如下，我们从首页通过点击link标签切换到isv-client页面，地址栏里是没有/admin的，虽然能正常显示，但是我们刷新页面后，因为CDS主应用是没有配置/system相关代理，本身也没有对应的路由页面，所以报错了404。

所以我们希望我们的前端路由切换是能够有/admin这样的前缀的，那么我们可以使用路由映射，通过给link标签设置带有/admin的as属性，这样地址栏origin后会显示为as属性值，这样地址栏里便有了/admin，由此解决了CDS主应用跳转系统配置项目后刷新页面报错404的问题。

（2）用前端代理解决独立部署下路由映射报错404的问题

继续（1）中的问题，我们配置了路由映射后，将系统配置项目独立部署，发现页面一刷新就会报错404，为什么？因为当我们点击按钮在浏览器端跳转时，因为是 SPA 应用，前端改变浏览器路由可以不刷新页面，是浏览器去找页面，它通过路由映射可以找到。而刷新的时候，是服务器去找，而我们的pages页面里面没有/admin/xxx的文件，所以就报404了。
解决办法：
方法一：利用 Node 框架（koa）处理，来替代 Next.js 默认自带的 server，对/admin/xxx的请求返回/xxx的页面即可。
方法二：
1.生产环境下，在libra发布平台上配置代理，把/admin的请求代理到本项目上这样。
2.开发环境下，在tuya的next框架下，config/index文件中配置base节点下的proxy属性即可。

2.服务端执行顺序

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.客户端执行顺序（首次打开页面）

1._app constructor()
2._app render()
3.page constructor()
4.page render()
注意： 当页面初始化加载时，getInitialProps 只会在服务端被调用。只有当路由跳转（ Link 组件跳转或 API 方法跳转）时，客户端才会执行 getInitialProps。

4.路由跳转执行顺序

1._app getInitialProps()
2.page getInitialProps()
3._app render()
4.page constructor()
5.page render()

参考文章

https://segmentfault.com/a/1190000041170750