用Flux的思想写前端

最近用React开发了公司的一个产品,写完之后发现代码特别乱且较难维护,早就得知Facebook设计了一个新的开发模式——Flux,今天就实践一下Flux的开发模式,体会体会久违的新鲜感。

Flux

Flux是一个全新的开发模式,与传统的MVC不同,Flux的设计中心是单向数据流。Flux有三个主要部分:Stores, Views(React组件), Dispatcher(唯一一个)。Views一般在此架构中位于顶层,它直接从Store中取出数据并展示。此外,Dispatcher是一个程序非常重要的组成部分,当View层接受一个用户的操作后,会产生一个Action,Action即操作,有时代表用户操作,有时代表服务端返回的Action,Action会带有业务数据,会经过Dispatcher分发给不同的Store,当Store获取到Action之后,会通知View进行更新。

其实Store的设计就是观察者模式的实践,一个Store可以理解为一个发布/订阅者,View订阅自己的Store,然后Store接收到Action之后会发布更新事件,此时View就会去主动获取Store中的数据,从而达到视图更新的目的。

Dispatcher

Dispatcher在一个Flux应用中是管理数据流的核心,它没什么复杂的,就是各个Store注册回调函数的地方,它就是一个简单的将Action分发给不同的Store的规则,每一个Store在注册自身的时候会提供一个回调函数,当Dispatcher收到Action时,所有注册过的Store会通过回调函数收到这个Action。

Store

Store包含了应用的状态和逻辑,它跟传统的MVC中的Model很像,但不同的是,它还管理着很多对象的状态,而不是像传统ORM那样仅仅对应一个对象,他跟Backbone的Collections很像,除此之外,Stores会在不同的domain下管理不同的状态。

Flux 适用场景

Flux的开发模式对不同组件间数据共享十分有用,比如聊天场景,当你发送一条消息给服务端时,产生一个Action,而此时的聊天列表的显示区不会跟你发送聊天内容的文本框耦合,当发送消息之后会使store更新,此时监听store的聊天列表会进行数据更新。

假如一些业务类型很简单的场景,并不推荐使用Flux模式,这样会有过度设计的嫌疑。

主要参考文章

Flux官方文档: http://facebook.github.io/flux/docs/overview.html