以同构之名，再谈 Redux/Vuex 的必要性

最近在菲麦社群中，有关 Redux/Vuex 是否真的需要的讨论异常激烈，我认为，在前端工程化的道路上， Redux/Vuex 非常有必要，在此前的文章中，我提到过：可以将 Vuex 认为是 Vue 的高级事件总线（redux 与 react 的关系类同），今天就以前后端同构为出发点，来谈谈它们的高级之处

一、同构的源动力

动态网页起初由服务器端脚本支撑，例如 Jsp、Asp 和 Php 等，也就是说，在当时，网页都是由服务端渲染的（这里的渲染指的是，将数据注入模板，渲染成 html，发回到浏览器），服务器端的 MVC 架构由此提出，模板由服务器端维护

得益于 Ajax 的发展，网页开始可以进行局部刷新，Js 通过发送 Ajax 请求拉取接口数据，再通过浏览器的 Dom 接口更新前端网页。这种形式，相比于此前用户每点击一个按钮、每发起一个互动皆需要通过服务器渲染，再全局刷新网页的体验要优异很多。既然前端有渲染的工作，那必然前端也需要模板，自然而然的衍生出前端 MV* ,基于 Angular、React 和 Vue 的各类 spa 架构，给人的感觉是，大家似乎已经暂时忘记了服务器渲染

忘记的理由并不是说 spa 已经足够完美，spa 同样有显著的问题，例如，用户必须忍受 bundle.js 下载以及随后的前端渲染的过程中的转菊花过程：

spa 首页加载过程

但是相比于前后端渲染同时存在导致的前后端需要维护两套模板，这点小缺陷似乎值得忍受。然而首屏直出一直以来都是 Web 应用的体验痛点，猿类并没有停止对前后端共用一套模板的探索，并且将 Js 扩展到后台的 Node 也让这一切成为可能

二、同构的原理

你可能知道，React 和 Vue 都有在后台渲染相应的 renderToString 方法，和配套的实践，先忘记这一切，假如是你来设计这一套，你会怎样画这个用例图？这么做的目的，更容易发现整个过程的难点，一起来试一下

首屏同构直出

图中蓝色字体中的在后端执行 jsBundle 渲染首页 html 的步骤，是一个难点，
React 和 Vue 对应的 renderToString 方法，正是为了解决这个问题而产生

但是我认为更为关键的步骤在于，黄色字体中，根据后台内置在 html 中的初始数据重新执行一次 JsBundle 渲染。这主要是由于前后端共用了一套 Js 逻辑，所以后端执行过的渲染过程，会由于前端 JsBundle 的执行而重新被调起，如何保证两次的渲染结果的一致性(渲染结果一致，最好的结果是不真实反应在真实的 dom 中，否则也会导致闪烁)？

当然，你可能会说，通过兼容性的代码，让前端不重复执行渲染即可，但这样无异于不让前端继承后端的执行状态，这就毫无同构可言了。所以这里执行两次，更为关键的是，继承后端的执行初始状态

三、面向数据的编程

前面说了，发送到前端的 jsBundle，要要能根据服务器端内置在 html 中的初始状态，重新渲染，并且渲染的结果要跟后端的渲染结果保持一致（最好是别在真实的反应到真实的dom 上面了），换句话说：

同样的输入要能得到同样的输出结果

要能高效的完成这个目标，就要求我们摒弃面向 dom 的编程，切换到面向数据的编程中，想象一下，面向 dom 编程的时候，我们常常需要做向某一个节点插入内容的操作，这个过程如果执行两遍，恐怕不容易保证一致性吧。好在 React 和 Vue 都是面向数据的编程（曾经你是不是以为它们最重要的是解决组件化而已）

得到同样的渲染结果，那只是完成了一个小目标，我们的真实目的是继承后端的初始状态，更好的衔接后续的各种 spa 操作，那就要要求

数据源是统一的，数据状态是可以追溯的

Redux/Vuex “高级”就高级在了这里，这应该可以回答开始关于 Redux 和 Vuex 必要性的问题了，如果还不能，那就再来理解下官方文档的开篇所写的动机

四、总结

服务器端渲染的好处其实还远不止此，还有 seo、静态化等等
同构的原理归原理，实践归实践，回头再说一说踩过的坑

想更快的了解，不如加微勾搭：facemagic2014