Ballade: 重新诠释 Flux 架构
由于 React 的单向数据流的设计,衍生出了单向数据流的架构模式 Flux。
在 MVC 的分层架构中,Flux 属于 M 层,也就是 Model,而在 Flux 中,Store 是关键部分,Action 和 Dispatcher 都是围绕着 Store 来设计的,所以 Flux 架构模式的目标就是基于单向数据流如何更好的管理数据,在 Views
或 Controller-views
与数据之间进行解耦。
我在之前的 React 应用的架构模式 Flux 有详细的介绍过 Flux 架构模式及其应用。
"Flux is more of a pattern than a framework."
这是 Flux 在其 github 主页上截取的一句话,翻译成中文就是:Flux 更像是一种架构模式,而不是一个单纯的框架。
从实际使用的感受来看,Flux 作为一种架构模式还是很不错的,方向是正确的,但是作为框架来使用,从这个层面来说,存在着一些问题。正是由于这些问题促使我重新基于 Flux 的架构模式开发了 Ballade。先来介绍一些 Ballade 的架构模式,之后再说说在使用 Flux 框架时碰到的一些问题以及 Ballade 是如何解决这些问题的。
Ballade 的架构介绍
Store
Store 是一个数据的存储中心,提供了「写入」和「读取」数据的接口,就像一个数据的「访问器」。
在 Views
或 Controller-views
(React 组件)中,只能从 Store 中「读取」数据,在 Store Callbacks 中,才能自由的「写入」和「读取」数据。
当数据变化的时候,Store 会发送一个数据变化的事件。
Store 的数据「访问器」分为 mutable(可变)和 immutable(不可变)的两种,分别对应了mutable 和 immutable 两种不同的数据结构。
Actions
所有的操作,像用户的交互行为或者从服务器获取一个数据,只要会引起数据变化的操作都可以把它看作是一个 Action,引起数据变化的操作可以是「写入」或「更新」数据。
如果想「写入」或「更新」Store 中的数据,只能发起一个 Action。每个 Action 都有一个唯一的 ActionType 和 payload 数据,ActionType 可以理解为这个 Action 唯一的名字,payload 数据就是传递给 Store 的数据。
Dispatcher
Dispatcher 用于连接 Actions 和 Store 的「调度员」,负责将 Action 产生的 payload 数据分发给指定的 Store。
Actions Middleware
在传送 payload 数据到 Store 时,可以注册一些中间件来处理 payload 数据,每个中间件会把处理完的 payload 结果再传递给下一个中间件。假如你想从服务器取数据,可以注册一个中间件。
Store Callbacks
当 Action 触发的时候,Store 需要一个与该 Action 对应的回调函数来处理 payload 数据,这时可以将数据写入到 Store 中。ActionType 需要与 Store 的回调函数名相对应。
与其它框架设计的异同
Ballade 在架构上和 Flux 很像,在一些细节问题上比 Flux 处理的更好或者说更具有约束性。
强化了 Store 的功能,正如我前面提到的 Flux 架构中 Store 是关键;
增加了 Actions Middleware 用于集中处理 Action,一方面简化了 Action 的功能,另一方面便于扩展;
Store Callbacks 的设计也做了简化,提升了封装性;
Actions Middleware 借鉴了 Redux 的 Middleware 的设计(当我知道 Redux 有 Middleware 但并不知道其实际应用和实现细节的时候,我就很自然的把这种 Middleware 设计用于了 Action)。Store Callbaks 与 Redux 的 Reducer 有些类似,但是对于已经熟悉了 Flux 架构的开发者来说,Store Callbacks 更好理解。
架构介绍完毕之后说说我以及我所在的团队在实际使用 Flux 框架时碰到的一些问题,相信其他使用 Flux 的开发者都会碰到这些类似的问题。
Flux 中的 Actions
先来看一段 Flux 的 Actions 的代码:
注意:本文所有的示例代码都是基于 ES6 语法的 JavaScript 代码。
// Flux 的代码 const actions = { fetchDatabasesource (query, type) { const url = `http://${window.__API_DOMAIN__}/api/database/datasource/${type}/${query}`; dispatcher.dispatchAsync({ url }, { request: constants.FETCH_DATABASESOURCE, success: constants.FETCH_DATABASESOURCE_SUCCESS, failure: constants.FETCH_DATABASESOURCE_ERROR }, { query: query }); } };
这是一段从服务端获取数据的 Action 的代码,dispatcher.dispatchAsync
封装了一个 fetch 方法用于取数据,该方法的实现可以查看在 github 的例子 dispatcher.js,该方法实际发起了三个 Action。
这里存在两个问题,一个是代码冗余的问题,(代码冗余的问题并不完全是由于框架本身造成的,也有可能是开发者的实现不够优雅)。还有一个问题就是职责不明的问题,取数据的操作到底该在哪里进行呢,是在 Action 中还是 Store Callback 中?这在 Flux 框架中并没有明确的约束。
注册 Actions 的中间件
在 Ballade 中,我们将从服务端取数据的 fetch 方法封装成一个 Actions Middleware,并注册到 dispatcher
上。
// Ballade 的代码 dispatcher.use((payload, next) => { // 可以通过中间件中是否包含 uri 字段来判断是否使用 fetch 来取数据 if (payload.uri) { fetch(payload.uri).then(function(response){ return response.json(); }) .then(function(response){ payload.response = response; // 异步函数中的 next 回调 next(payload); }); } // 如果不包含 uri 字段,则不作任何处理 else { next(payload); } });
Ballade 中简化的 Actions
然后上面的 Actions 代码在 Ballade 中可以简化成下面这样:
// Ballade 的代码 const actions = dispatcher.createActions({ fetchDatabasesource (query, type) ({ uri: `http://${window.__API_DOMAIN__}/api/database/datasource/${type}/${query}`, query: query }) });
在 Ballade 的 Action 中,直接返回 ActionType 和 payload 数据即可(这里使用了 ES6 的箭头函数省略了 return
关键字)。
Flux 中的 Store Callback
继续发一段 Flux Store Callback 的代码。
// Flux 的代码 libraryPermissionsStore.dispatchToken = dispatcher.register((action) => { switch(action.type) { case constants.FETCH_DATABASESOURCE: updateDatabasesource({ isLoading: true },action.query); libraryPermissionsStore.emit(constants.CHANGE_DATABASESOURCE_EVENT); break; case constants.FETCH_DATABASESOURCE_SUCCESS: action.response.isLoading = false; updateDatabasesource(action.response, action.query); libraryPermissionsStore.emit(constants.CHANGE_DATABASESOURCE_EVENT); break; ... });
这段代码和上面的创建 Actions 的代码相对应,用于存储数据到 Store 中并发出数据变化的通知(这样Views
或 Controller-views
才能接收到通知),它是一个大的 Callback 函数,使用 switch case 语句与 ActionType 对应,但是 switch case 容易造成代码冗余,并且每个 case 语句中都需要手动发送一次通知。一个大的 Callback 函数中如果 switch case 语句过多还存在着变量无意中共享作用域的隐患。
Ballade 中简化的 Store Callback
Ballade 在 Store Callbacks 中将大的 Callback 和 switch case 语句拆分成了一个个独立的 Callbacks,并且使用函数的 name 与 ActionType 进行对应。
// Ballade 的代码 const exampleStore = dispatcher.createMutableStore(schema, { 'example/update-title': function (store, action) { return store.mutable.set('title', action.title); }, ... });
先看看 example/update-title
这个 Store Callback,没有了 switch case 语句,也无需每次都发送一个数据变化的通知,只要返回 Store 的 set 或 delete 操作的结果,框架内部会自动发送通知。
schema
在 Ballade 中,要创建一个 Store 需要先声明 schema
。
const schema = { title: null, meta: { votes: null, favs: null } };
schema
就是该 Store 的数据模型,只有数据的 key 在 schema
中声明过,才能对其进行「写入」或「更新」数据,这可以让开发者知道该 Store 中有哪些数据,能让数据操作更加清晰透明。
假如 schema
中并没有声明 author
,而又想直接存储该数据到 Store 中是不会生效的,或者直接报错。
// 无效的操作 store.mutable.set('author', action.author); // 报错 store.immutable.set('author', action.author);
mutable & immutable
Ballade 的 Store 对 mutable 和 immutable 两种数据结构都支持。
在默认的 ballade.js 版本中,提供的是 mutable 版本,使用 dispatcher.createMutableStore
就可以创建一个 mutable 的 Store,mutable 数据的「写入」和「读取」都需要通过 store.mutable
这个数据访问器。
在 ballade.immutable.js 版本中,提供了 mutable 和 immutable 两个版本,但是需要依赖 immtable-js。使用 dispatcher.createImmutableStore
就可以创建一个 immutable 的 Store,immutable 数据的「写入」和「读取」都需要通过 store.immutable
这个数据访问器,实际上 store.immutable
就是基于 Immutable 实例的一个封装。
「写入」和「读取」分离
通过 dispatcher.createMutableStore
或 dispatcher.createImmutableStore
创建的 Store 用于在 Views
或 Controller-views
中「读取」数据,它们不能直接「写入」数据。
// 从 store 中取出 titile exampleStore.mutable.get('title'); console.log(exampleStore.mutable.set) // => undefined
对于 mutable 访问器来说,并没有 set 方法。并且如果返回的数据是一个引用类型的数据(对象或数组),它会返回该数据的拷贝,这样在 Store Callbacks 之外对取出来的数据进行修改并不会影响到 Store 中保存的数据。
// 如果 title 是一个对象, title = { foo: 'bar' } // 会返回 title 的克隆对象 var title = store.mutable.get('title'); console.log(title.foo) // => 'bar' title.foo = 'baz'; console.log(title.foo) // => 'baz' console.log(store.mutable.get('title').foo) // => 'bar'
而对于 immutable 访问器来说,它的 set 类方法只会返回一个新的 immutable 数据,也不会影响 Store 中的数据。
只有在 Store Callbacks 中才能自由的「写入」和「读取」数据。这种分离的设计充分体现了「单向」的特点,使数据操作清晰明了。
Action 真的需要队列吗?
// Flux 的代码 componentDidMount () { orgPermissionsStore.on(DELETE_APPLICATION_SUCCESS_EVENT, this.deleteSuccess); } … deleteSuccess () { // 无奈之举 setTimeout(() => { orgPermissionsActions.fetchApplication(1); }, 0); }
这段代码是当一个删除操作的 Action 成功之后,再发起一个请求数据的 Action,如果没有 setTimeout
的包装,Flux 框架就会报如下的错误:
"Dispatch.dispatch(…): Cannot dispatch in the middle of a dispatch"
这是因为 Flux 框架在设计的时候,一次只能发起一个 Action,这么做的目的可能是为了 Store 之间的依赖,也有可能是为了确保数据一致性而设计的类似于「并发锁」,这样每次只会有一个修改数据的操作,如果要同时发起好几个请求数据的 Action 就会有问题,要么简单粗暴的使用 setTimeout
来规避,要么使用 Action 队列来解决。但是 JavaScript 在目前来看,它还是单线程的,不会出现并发的场景。
在 Ballade 并没有这种设计。
订阅事件
Store 集成了一个简单的事件订阅和发送的系统,在 Views
或 Controller-views
中可以通过 store.event
接口来订阅数据变化的事件,并且通常的情况下无需开发者主动发送事件通知,只要数据有变更由框架自动来发送事件通知。
// 如果 titile 有变化,回调函数则会执行 exampleStore.event.subscribe('title', function () { var title = store.mutable.get('title'); console.log(title); // or var title = store.immutable.get('title'); console.log(title); });
你其实不需要 waitFor
在 Flux 中,它提供了一个 waitFor
来处理 Store 之间的依赖,这并不是一个好的设计,只会让应用变得更复杂。在 flux/examples/flux-chat/js/stores/MessageStore.js 这个例子中,如果删除下面这行代码,该例子仍然能很好的运行。
ChatAppDispatcher.waitFor([ThreadStore.dispatchToken]);
当然,这里并不是说 waitFor
一无是处,只是它让开发者对 Flux 的理解更加困惑。
在 Ballade 中处理 Store 之间的依赖,相当简单,就像你要使用一个变量,那么你得先定义这个变量,它本来就这么简单。
var storeA = dispatcher.createMutableStore(schema, { 'example/update-title': function (store, action) { return store.mutable.set('title', action.title); } }); // 假如 storeB 依赖了 storeA var storeB = dispatcher.createMutableStore(schema, { 'example/update-title': function (store, action) { var title = storeA.mutable.get('title') + '!'; return store.mutable.set('title', title); } });
好了,Ballade 都介绍完了,如果你对 Ballade 感兴趣,想深入的了解,下面是 Ballade 的一些资源。
github 主页:https://github.com/chenmnkken/ballade
中文文档:https://github.com/chenmnkken/ballade/blob/master/README_CN.md
Mutable 的例子:TodoMVC
Immutable 的例子:TodoMVC
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:雨夜带刀 来源: 雨夜带刀
- 标签: Ballade Flux
- 发布时间:2016-03-21 00:25:19
- [66] Go Reflect 性能
- [66] Oracle MTS模式下 进程地址与会话信
- [65] 如何拿下简短的域名
- [59] IOS安全–浅谈关于IOS加固的几种方法
- [59] android 开发入门
- [59] 图书馆的世界纪录
- [58] 【社会化设计】自我(self)部分――欢迎区
- [53] 视觉调整-设计师 vs. 逻辑
- [47] 界面设计速成
- [47] 读书笔记-壹百度:百度十年千倍的29条法则