React 服务端渲染与预渲染

仍是SPA

需要用到 react-router-config 这个库，它可以根据 route 匹配到对应的组件，拿到当前route对应的组件是实现路由同步的关键，再通过组件的静态API方法获取接口数据

主要是在服务端通过组件的静态API方法获取接口数据后创建store，再通过 window. store = store 传递给前端

主要是要将前端的 js 文件附加在服务端渲染的模板 html 文件中

服务端渲染的应用场景：一般只是对重要的页面，如首页才会做，可以提高首屏加载速度，利于SEO。其他页面实际上仍是CSR

预渲染不像服务器渲染那样即时编译 HTML，它只在构建时为了特定的路由生成特定的几个静态页面，等于我们可以通过 Webpack 插件将一些特定页面组件 build 时就编译为 html 文件，直接以静态资源的形式输出给搜索引擎。

1、SPA变为MPA

2、必须使用 History 路由，而不能使用 Hash 路由，所以对于没有做预渲染的页面往往需要服务器配置路由，如nginx 配置如下：

3、对于动态路由，如 /detail/:id ，是不支持的，不过可以换成 query 路由，如 /detail?id=

4、应用场景比较有限，能想到的就是骨架屏应用，比如首页，为了速度，我们会用一些骨架屏组件，如果不做预渲染，则骨架屏组件会等整个js文件加载完毕才开始渲染，体验不好。如果做了预渲染，则当html文件加载完毕时就会开始渲染了

1 一开始，html 就是后端渲染的。不过后端发现页面中的 js 好麻烦（虽然简单，但是坑多），于是让公司招聘专门写 js 的人，也就是前端

2 前端名义上是程序员，实际上就是在切图（CSS）和做特效(JS)，所以所有程序员中前端工资最低，职位也最低。所以前后端的鄙视链就出现了

3 nodejs 和前端 mvc 的兴起让前端变得复杂起来，前端发现翻身的机会，于是全力支持这两种技术，造成本不该做成 spa 的网站也成了 spa。慢慢地前后端分离运动从大公司开始兴起，目的就是前端脱离后端的指指点点，独立发展。（表面上是为了「代码分离」，实际上是为了「人员分离」，也就是「前后端分家」，前端不再附属于后端团队）

4 spa 之后发现 seo 问题很大，而且首屏渲染速度贼慢，但是自己选的路再难走也要走下去，于是用 nodejs 在服务端渲染这一条路被看成是一条出路

5 其实这是第二个翻身的机会，如果 nodejs 服务器渲染成为主流，其实就相当于前端把后端的大部分工作给抢了，工资压过普通后端指日可待

6 然而结果是 nodejs 服务端渲染始终是小众，因为后端也没那么脆弱，java php rails 十多年沉淀的技术岂是你说推翻就推翻的，已经运行多年的项目又岂是容你随便用 nodejs 重写的，另一方面 golang 等技术的兴起也给 nodejs 不少压力。最终只有少部分前端特别强势的团队成功用上了 Node.js 做渲染（比如阿里的一些团队），大部分公司依然是用 PHP 渲染 HTML。

7 于是 nodejs 退一步说好好好我不抢你们的工作，我只做中间层（大部分工作就是渲染页面和调用后台接口），绝不越雷池。后端说算你识相。现在 nodejs 主要搞什么微服务，也是为了抢后端还没注意的市场。

你要看一门技术的发展主要应该看背后的人是谁，应用场景是哪些，最后才是技术细节。

react.js在服务器端渲染好处：

提升性能是需要再浏览器端的性能提升还是服务端的 性能提升，是两个概念，服务端渲染会给服务端造成一定的压力，减轻客户端的压力；好处：在整个页面级别的应用会使得浏览器在解析dom完成之后马上有东西可以渲染。再者就是对seo比较友好一些；

渲染的流程主要是：

准备数据，一般从数据库或外部API获得 (一般要先 render React 一次，去触发所需的API)

数据和React结合生成HTML Markup

除了把HMTL Markup输出外， 还要把'State'输出，这要在客户端才能保留'State'

---