使用 Immutable Subject 来驱动 Angular 应用

现状

最近在重构手上的一个 Angular 项目,之前是用的自己写的一个仿 Elm 架构的库来进行的状态管理,期间遇到了这些痛点:

  1. 样板代码太多
  2. 异步处理太过繁琐
  3. 需要单独维护一个 npm 包

其中,一、二两点是促使我重构的原因,第三点是促使我更换状态管理方案的理由(太懒了,根本不想去维护这个项目)。

样板代码太多

Elm 架构中,有下面几个重要的概念:

  1. Message(在 Redux 中被称作 Action)
  2. Update(在 Redux 中被称作 Reducer)
  3. Model

这三个概念用 Elm 代码来实现显得非常优雅:

  1. Message:可区分联合(Discriminated Union),还可以在单独的 Case 中使用元祖来内联复杂数据结构
  2. Update:对可区分联合使用模式匹配
  3. Model:不可变记录类型(Record Type),方便基于当前的值生成新的值

但是 JS 并没有这些语言特性,大部分的行为需要靠大量额外的代码来模拟,而且模拟的效果也只是差强人意。

异步处理太过繁琐

在处理异步操作的时候,我们往往需要处理三种状态:请求中、成功、失败,这放在 Elm 中,往往需要三个 Message 才能进行完整的描述,而且还需要 3 个对应的 Update 分支,用 Elm 来写的话其实也还好,但是如果要用 JS 来实现的话,那可真是让人头大。

备选方案

NgRx

这是 Angular 生态中最强大的专门用来做状态管理的库了,流行度可以排上 No.1。各种各样的配套设施非常齐全,而且对 Redux 用户、RxJS 用户比较友好,不过这两个优点也就意味着它对新手不太友好,而且代码量与我现在的方案相比也很难减少。同样的,它所支持的全局单一状态让我不是特别感冒,如果可以的话,我更希望能够使用模块单一状态。

NgXs

这是一个简化版的 NgRx 库,相较于 NgRx 来说,它要显得简洁很多,但是还是免不了写那么多的样板代码(Action 之类的东西),而且同样也不支持我想要的模块单一状态。

akita

这是一个对框架无依赖的状态管理库,但是从样例代码风格上来看,更适合 OOP 风格的 Angular。它支持多个 Store,也支持在任意位置修改 Store(官方建议在一个专门的 Service 中修改 Store),这两点让它看起来更像是一个 OO 的 MobX。在最开始接触到这个库的时候,我已经非常心动了,基本上满足了我的大多数需求,不过在稍微进行了一些实践过后,还是选择了放弃,因为太过 OO,所以样板代码又通过另一种方式膨胀了起来。

MobX

MobX 理念我非常喜欢,所以我原本是很想把 MobX 跟 rxjs 搭配使用的,但是 MobX 来到 Angular 应用中后显得有些水土不服,在很多地方都需要手动的将把 RxJS 与 MobX 进行来回的转换,这大大的增加了我的重构成本,最终只能作罢。

最终方案

最终,我没有选择以上任何一种备选方案,而是选择使用 immutable 与 RxJS 来混搭一个状态管理方案—— ImmutableSubject

其源码如下所示:

import { BehaviorSubject } from 'rxjs';

export class ImmutableSubject<TImmutable> extends BehaviorSubject<TImmutable> {
    update(action: (value: TImmutable) => TImmutable) {
        this.next(action(this.value));
    }
}

我仅仅只是为 BehaviorSubject 做了一点点的拓展,让调用方更方便地修改 Store。使用起来就像下面这样:

import { Injectable } from '@angular/core';
import { ImmutableSubject } from './ImmutableSubject';
import { List } from 'immutable';
import { BlogCategoryEditDto } from '../models/BlogCategoryEditDto.model';
import { CategoriesService } from '../api/categories.service';
import { BlogCategoryType } from '../models/BlogCategoryType.enum';

@Injectable()
export class CategoryStore {
    constructor(
        private cateSvc: CategoriesService
    ) { }
    
    /// ======= Queries =======
    
    $categories = new ImmutableSubject(List<BlogCategoryEditDto>());
    
    /// ======= Actions =======

    refreshList(cateType: BlogCategoryType) {
        this.cateSvc.list(cateType).subscribe(categories => {
            this.$categories.update(x => {
                return List(categories);
            });
        });
    }

    addCategory(dto: BlogCategoryEditDto) {
        this.$categories.update(x => x.push(dto));
    }

    deleteCategory(categoryId: number) {
        this.$categories.update(x => x.filterNot(c => c.categoryId === categoryId));
    }

    updateCategory(dto: BlogCategoryEditDto) {
        this.$categories.update(x => x.map(c => c.categoryId === dto.categoryId ? dto : c));
    }
}

Store 类中使用 ImmutableSubject 作为真正存储数据的地方,同时使用两行注释将查询与修改进行分离开来,从形式上极大地减少了样板代码的出现。

对于异步操作来说,可以直接让 Action 返回一个 Observable 来指示异步处理的过程,而 Query 本身就是 Observable ,所以可以自然而然的获得处理异步的能力,而这并不需要添加太多额外的代码。

Immutable 为我们提供了大量使用的不可变数据结构,可以在 JS 中实现 Record Type 大部分的特性。

Immutable 与 RxJS 都是非常出名的第三方库,所以根本不需要费心去维护升级,而且它们的维护者也非常的可靠,在未来很长一段时间内它们也都可以获得及时的更新。

尽管我的 ImmutableSubject 看起来非常的简陋,但他确实可以在一定的约束下为我解决问题。在使用 ImmutableSubject 的时候需要遵守以下约定:

  1. Store 中的状态应该是 immutable
  2. 对状态的修改只能在 Store 类的 Actions 中使用 update 方法进行
  3. Query 应该总是使用 pipeImmutableSubject 中派生
  4. 不再使用的 ImmutableSubject 需要手动释放

关于 EventSourcing

使用类似 Elm 架构的一个好处就是可以使用“时间旅行”功能,因为所有对状态的修改都会被记录下来,或者说,当前状态就是由历史操作记录积累而成(即事件溯源)。不过这个功能我并不需要,对于我现在的应用规模来说,事件溯源不仅不能直接解决任何问题,反而会提高代码的复杂性。对于我来说,仅仅只是 CQRS 就已经足够了。

posted @ 2019-01-15 12:03  不如隐茶去  阅读(736)  评论(0编辑  收藏  举报