我学 Flux

Flux 是 fb 用来开发客户端型的 web 应用的一种架构设计. 它组合了 React 兼容的视图组件, 使用单向的数据流. 它更加趋向于一个架构设计而非框架.

Flux 主要有几个大部分组成

dispatcher
stores
view(react components)

不同于更加常见的MVC, 在 flux 里没有我们所谓的 controller, 而是一种叫做 controller-view 的东西. 视图通常在顶部首先从 store 哪里得到数据, 然后把这些数据再往下面分配, 另外, 动作创建者还有指派帮助方法,他们通常用来支持一些语义话的 API 用来描述应用里有可能发生的动作.

Flux 使用一种单向的数据流当一个用户和 React 的视图交互的时候, 视图传送一个动作到中央的指派器, 然后到达 store, 他们用来保存应用的数据和一些逻辑, 他们会更新所有相关的视图状态. 这个和 react 的指令编程方式很切合. 这个就允许 store 发送一些特定的更新操作来改变状态.

我们起初是在正确的搞定数据, 例如我们面对一个未读消息数的 case, 同时我们还在面对一个对话的 list case, 而我们需要高亮未读消息的时候,这个情况下 mvc 就比较困难处理起来,--当把某条对话标记为已读会去更新这个对话 model, 而这个时候就要附带的修改未读对话的 model. 像这样的侧层级附带更新操作在大型的 mvc 程序里会经常遇到. 结果不可预测.

在 flux 理我们把 controller 这个角色倒置给 stores, 这个 store 它可以接受更新等操作, 而不取决于外部的更新.他们不会任意呗外界修改,通常只有注册给分配器的回调函数才可以更新数据的状态.

结构和数据流

数据在 Flux 里是单向的

这个是 Flux 的核心概念, dispatcher, stores, view 他们之间是独立的.

视图会对于用户的交互指定特定的动作来给 dispatcher, 然后找到对应的 store, 修改状态, 然后 store 会对于相关的视图做出同步动作.

action creator 就是一些帮助类, 给他们指定类型,然后给 dispatcher 使用
每一个动作会被发送到所有的 stores 那些通过 callback 已经注册到 dispatcher 里的.
当 store 在完成数据状态更新之后,会触发 change 的事件. 而有一个特定的视图-> controller-view 他们会监视这些事件,然后一单有新数据就会拿新数据更新所有的视图.

We found that two-way data bindings led to cascading updates, where changing one object led to another object changing, which could also trigger more updates. As applications grew, these cascading updates made it very difficult to predict what would change as the result of one user interaction. When updates can only change data within a single round, the system as a whole becomes more predictable.

我们发现双向数据绑定就引发层级更新,而程序越庞大层级更新的范围就不可控, 就无法知道预测一个用户的操作会诱发多少相关的更新, 当一个更新只有一个确定的更新范围这个系统就是可测的.

单个 dispatch

这个分发器会管理整个flux 应用的数据流,作为一个中央处理器. 它本身没有什么含量在. 就是简单注册了各种视图回调到 store里. 当一个动作创建者触发一个新的动作,所有的有注册的 store 都会收到回调事件.

stores

包含应用状态,逻辑. 他们的角色类似 mvc架构里的 model. 但是他们管理很多对象的状态.-- 他们不会去对应到实际的比如 ORM 里的一条记录. 或者类似 backbone 里的一个集合. 他们更像是在对应整个 ORM 里一系列的数据集合. 管理一个应用中特定的 domain 的数据状态.

视图和控制视图

React 给视图层提供了很多种可以组件化而且自由渲染的视图.在这里最接近视图树最上层,一种特殊的用来监听所有事件来广播给 store 事件的,我们称之为 controller-view. 其实它很简单,就是从 store 里拿到数据,然后分发到后代的节点.

当它从 store 哪里得到事件, 然后通过 store 里的公共方法拿到数据, 接着调用自己的 setState()或者 forceUpdate() 方法,接着通过 render() 方法把事件传递给后代.

动作

分发器暴露了一个方法, 它允许我们能够触发一个分发到 store, 这个分发里包含请求的数据, 我们把这个分发称之为动作.如何创建这个动作,可能会封装到一个语义的帮助方法里, 用来发送动作到分发器, 如我们要修改已经添加到 list里的 item 的内容,我们就创建一个 updateText(todoId, newText)的方法, 在 TodoActions 然后它就会在视图的事件处理器哪里被触发.我们可以触发它作为用户交互的响应. 这个动作创建也会添加一个 type 到这个动作,所以当一个动作在 store 里触发它就可以找出对应的,如我们把这个动作起名为TODO_UPDATE_TEXT.

to be continued---