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
• Bug 或问题提交：https://github.com/chenmnkken/ballade/issues