Redux架构实践(一)

——Single Source of Truth

在现代前后端分离的系统架构中,后端负责数据处理,前端负责数据展示。这种架构能够有效的分离数据处理和数据展示的逻辑,让同一套数据处理逻辑可以被不同的数据展示逻辑复用。这里的复用现在大部分是基于Restful的API协议。

理想是很丰满的,现实缺很残酷。在有复杂的业务数据结构的情况下,我们常常会遇到不同的API返回了同样的数据,如果不同的component的显示直接依赖于API数据的返回,很有可能就会有不同的component对于同样的数据所显示的结果不一样的bug。再加上缓存、用户修改数据等等复杂情况,显示不一致的问题可能更加严重,所以为了解决这个问题,Single source of truth(以下使用中文名称:单一数据源)的概念被提出来了。下面我们就来看看在基于Redux的应用中如何做到单一数据源。

聊一聊基于Flux的前端系统

——基础架构以及演进

在最近的一个项目中,我们团队尝试了Flux + React.js的架构,在这种架构中我们获得了很多的好处:

  • 数据流更加清晰和简单,使得我们的开发和debug也可以按照一个清晰和标准的方式进行;
  • 数据处理这一层的职责更加清晰,使得我们可以更容易的进行数据维护、缓存的处理;
  • 在界面的处理上只用关心界面的最终状态,不需要维护中间过程;
  • ……

下面我们就来聊一聊我们团队在这种架构中的一些实践,希望可以对大家有用。

用React.js替换Backbone.js的View(二)

——Todo MVC示例

Backbone.js和React.js在设计思想上都借鉴了Reactive Programming,即:当Model修改时,这种变更可以反向传播到View,使得View同时被更改,也就是双向绑定。但Backbone.js需要你自己来写如何修改View,而在React.js中,你只需要关心如何根据Model来显示View,如何修改可以完全交给React.js。也就是说他们都在做一种简化,而React.js做的更加彻底,这也是它的核心思想和优点。

真正的学习还是需要写代码,所以这里用经典的Todo MVC作为示例。所有的代码可以在我的Github上找到。

用React.js替换Backbone.js的View(一)

——Backbone.js View的陷阱以及React.js的优点

最近终于找到时间,学习了一下Facebook出品的React.js,发现虽然没有很深的体会到性能上的好处,但是这种编程方式带来的好处确实是很大的。这里我准备跟Backbone.js的View做一下对比,同时下一篇文章中提供一个示例说明一下如何用React.js替换Backbone.js的View。