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文件加载完毕时就会开始渲染了

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

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

渲染的流程主要是：

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

数据和React结合生成HTML Markup

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

React速度很快与其它框架相比，React采取了一种特立独行的操作DOM的方式。它并不直接对DOM进行操作。它引入了一个叫做虚拟DOM的概念，安插在JavaScript逻辑和实际的DOM之间。这一概念提高了Web性能。在UI渲染过程中，React通过在虚拟DOM中的微操作来实对现实际DOM的局部更新。跨浏览器兼容虚拟DOM帮助我们解决了跨浏览器问题，它为我们提供了标准化的API，甚至在IE8中都是没问题的。模块化为你程序编写独立的模块化UI组件，这样当某个或某些组件出现问题是，可以方便地进行隔离。每个组件都可以进行独立的开发和测试，并且它们可以引入其它组件。这等同于提高了代码的可维护性。单向数据流让事情一目了然Flux是一个用于在JavaScript应用中创建单向数据层的架构，它随着React视图库的开发而被Facebook概念化。它只是一个概念，而非特定工具的实现。它可以被其它框架吸纳。例如，AlexRattray有一个很好的Flux实例，在React中使用了Backbone的集合和模型。纯粹的JavaScript现代Web应用程序与传统的Web应用有着不同的工作方式。例如，视图层的更新需要通过用户交互而不需要请求服务器。因此视图和控制器非常依赖彼此。许多框架使用Handlebars或Mustache等模板引擎来处理视图层。但React相信视图和控制器应该相互依存在一起而不是使用第三方模板引擎，而且，最重要的是，它是纯粹的JavaScript程序。同构的JavaScript单页面JS应用程序的最大缺陷在于对搜索引擎的索引有很大限制。React对此有了解决方案。React可以在服务器上预渲染应用再发送到客户端。它可以从预渲染的静态内容中恢复一样的记录到动态应用程序中。因为搜索引擎的爬虫程序依赖的是服务端响应而不是JavaScript的执行，预渲染你的应用有助于搜索引擎优化。React与其它框架/库兼容性好比如使用RequireJS来加载和打包，而Browserify和Webpack适用于构建大型应用。它们使得那些艰难的任务不再让人望而生畏。不幸的是，目前的JavaScript版本并没有提供一个打包和加载的模块。（在未来的ES6版本上将使用System.import来解决这个问题）。幸运的是，我们有RequireJS和Webpack这些漂亮整洁的替代品。React是由Browserify构建的，如果你想操作图像资源或者编译Less和CoffeeScript，Webpack或许是一个更好的选择。

---