为什么会去了解ssr
最近作者工作有变动，去维护一个ssr的项目，为了更好的去维护，所以花了一点时间去了解这一块。
当前渲染模式
客户端渲染
所谓的客户端渲染，其实就是指的浏览器发起请求，服务端返回一个html，这个html拥有一个简单的骨架但是没有内容。然后浏览器解析html，会请求一个js，这个js执行会去操作dom添加内容。
优点
- 前后端分离
- 不利于seo
- 页面切换没有白屏等待,交互更流畅，所有的操作都是监听url的变化去替换内容
缺点
- 首屏加载问题，因为打包工具会把全部页面和页面之间的关系打包成一个bundle，所以会导致这个js文件很大，所以会导致首屏加载慢。
服务端渲染
所谓的服务端渲染，其实就是指的浏览器发起请求，服务端返回一个html，这个html拥有完整的内容，生成内容的过程是由服务端来做。举个例子：php使用smart的模板，node会使用对应的模板引擎。
优点
- 有利于seo
- 没有首屏加载慢的问题
缺点
- 白屏等待
- 前后端不分离，前端不够灵活,问题不好排查。这里问题排查，作者之前做端内h5的需求使用的是打包分页 + 后端渲染。遇到问题需要看后端代码，十分不好定位。
客户端渲染+服务端渲染
这里指的是ssr，目前的ssr不是传统的服务端渲染，而是首屏是服务端渲染而非首屏则是spa的单页面程序。实际上就是首屏渲染是由服务端完成内容填充、数据注入生成完整的html然后下发到浏览器，浏览器还会去解析js bundle，非首屏和spa是一样的。
优点
- 有利于seo
- 没有首屏加载慢的问题
- 页面切换没有白屏等待
缺点
- 上手门槛高
- 前端需要维护一套bff
seo的一些看法
做seo还是得去研究搜索引擎的排序的规律。keyword、desc、title在这里就不用说了。作者之前有个老师是专门做seo，和这位老师学到了不少东西。我认为做seo最好的办法是蹭热度。例如juejin.cn是个热门网站，我就会尝试看能不能测一波热度，看看juejin1.cn、juejin12.cn等等域名。
ssr实践探索
现在有很多集成的框架，开箱即用。例如next.js。所以很多时候直接用就行了，不够我们还是得知道其原理，这样写需求和定位问题才能更快更好。
ssr核心-同构
同构指的就是一套代码即在服务端运行、又在客户端运行。那么因为环境不一致就会导致出现很多问题。主要问题有这几个？
- 路由怎么维护
- 数据获取逻辑放在哪里
- 节点怎么复用
路由同构
对应路由来说，我们可以维护同一份路由配置
- 服务端根据 req path 拿到对应组件 通过renderToString翻译成html
- 客户端 浏览器还是和之前spa一样，都是根据url来渲染对应组件
数据同构
主要是数据获取逻辑放在哪里，为了方便和代码的复用性，例如类组件，我们可以导出一个静态方法，那么服务端渲染的时候只要调用该方法就能获取到数据，客户端渲染的时候也能复用代码。
渲染同构
渲染同构是指要保证两端数据的一致性，不然如果保持不了一致性的话会导致闪烁问题。
数据注水
当服务端获取数据之后，会把数据注入到html里面，让浏览器可以调用该数据。
数据脱水
当客户端渲染的时候，就会进行数据脱水，拿到服务端注入的数据，把数据注入组件，可以注入context、或者redux里面。然后再进行事件绑定。
css ssr
因为服务端不能解析样式，所以我们一般会进行配置在服务端忽略样式的导入，当然也有其他方案。这里就不阐述了。
注意点
- 服务端环境和客户端客户端不一样，所以组件生命周期只会执行constructor以及render。
- 注意区分浏览器、服务器执行的逻辑。
- ssr是服务端进行内容填充的时候会执行一遍逻辑，到浏览器还会执行一遍，浏览器这一遍主要是进行事件绑定，把所有权交给浏览器。
- react renderToString会忽略事件绑定，hydrate的时候会进行dom复用。
- 注意数据的一致性，否则会出现闪烁问题。
总结
写的匆忙，很多内容没有写上去，就把这篇当作小笔记。
