最近在菲麦社群中,有关 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 下载以及随后的前端渲染的过程中的转菊花过程:
二、同构的原理
你可能知道,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