使用 RxJS 實現一個簡易的仿 Elm 架構應用

使用 RxJS 實現一個簡易的仿 Elm 架構應用

標籤（空格分隔）： 前端

---

什麼是 Elm 架構

Elm 架構是一種使用 Elm 語言編寫 Web 前端應用的簡單架構，在代碼模塊化、代碼重用以及測試方面都有較好的優點。使用 Elm 架構，能夠很是輕鬆的構建複雜的 Web 應用，不管是面對重構仍是添加新功能，它都能使項目保持良好的健康狀態。

Elm 架構的應用一般由三部分組成——模型、更新、視圖。這三者之間使用 Message 來相互通訊。

模型

模型一般是一個簡單的 POJO 對象，包含了須要展現的數據或者是界面顯示邏輯的狀態信息，在 Elm 語言中，一般是自定義的「記錄類型」，模型對象及其字段都是不可變的（immutable）。使用 TypeScript 的話，能夠簡單的用接口來描述模型：

export interface IHabbitPresetsState {
    presets: IHabbitPreset[];
    isLoading: boolean;
    isOperating: boolean;
    isOperationSuccess: boolean;
    isEditing: boolean;
}

這時候，咱們就須要在心中謹記，永遠不要去修改模型的字段！

Message

Message 用來定義應用程序在運行過程當中可能會觸發的事件，例如，在一個秒錶應用中，咱們會定義「開始計時」、「暫停計時」、「重置」這三種事件。在 Elm 中，可使用 Union Type 來定義 Message，若是使用 TypeScript 的話，能夠定義多個消息類，而後再建立一個聯合類型定義：

export type HabbitPresetsMsg =
    Get | Receive
    | Add | AddResp
    | Delete | DeleteResp
    | Update | UpdateResp
    | BeginEdit | StopEdit;

export class Get {
}

export class Receive {
    constructor(public payload: IHabbitPreset[]) { }
}

export class Add {
    constructor(public payload: IHabbitPreset) { }
}

export class AddResp {
    constructor(public payload: IHabbitPreset) {
    }
}

export class Delete {
    constructor(public payload: number) {
    }
}

export class DeleteResp {
    constructor(public payload: number) { }
}

export class Update {

    constructor(public payload: IHabbitPreset) {
    }
}

export class UpdateResp {
    constructor(public payload: IHabbitPreset) {
    }
}

export class BeginEdit {
    constructor(public payload: number) { }
}

export class StopEdit {
}

咱們的應用程序通常從視圖層來觸發 Message，好比，在頁面加載完畢後，就當即觸發「加載數據」這個 Message，被觸發的 Message 由更新模塊來處理。

更新

更新，即模型的更新方式，一般是一個函數，用 TypeScript 來描述這個函數就是：

update(state: IHabbitPresetsState, msg: HabbitPresetsMsg): IHabbitPresetsState

每當一個新的 Message 被觸發的時候，Elm 架構便會將應用程序當前的模型跟接受到 Message 傳入 update 函數，再把執行結果做爲應用程序新的模型——這就是模型的更新。
在 Elm 程序中，視圖的渲染僅依賴模型中的數據，因此，模型的更新每每會致使視圖的更新。

視圖

Elm 語言自帶了一個前端的視圖庫，其特色是視圖的更新僅依賴模型的更新，幾乎全部的 Message 也都是由視圖來觸發。但在這篇文章裏面，我將使用 Angular5 來演示效果，固然了，也可使用 React 或者 jQuery 來實現視圖，這取決於我的愛好。

小結

至此，咱們大體的瞭解了一下 Elm 架構的幾個要點：模型、更新、視圖以及 Message。一個 Elm 架構的程序，一般是視圖由於用戶的動做觸發特定 Message，而後由這個觸發的 Message 跟當前應用的模型計算得出新的模型，新的模型的產生使得視圖產生變化。

開始實現

首先讓咱們寫出一個空的框架：

export class ElmArch<TState, TMsgType> {
}

TState 表示應用程序的模型類型，TMsgType 表示應用程序的消息聯合類型。

由上一節能夠知道，Message 是應用程序可以運行的關鍵，Message 在運行時要可以手動產生，而且，Message 的觸發還要能被監聽，因此，可使用 RxJS/Subject 來構建一個 Message 流。

export class ElmArch<TState, TMsgType> {
    private readonly $msg = new Subject<TMsgType>();
    send(msg: TMsgType) {
        this.$msg.next(msg);
    }
}

這裏之因此定義一個 send 函數是爲了更好的將代碼封裝起來，消息流對外只暴露一個觸發消息的接口。

接下來，咱們能夠考慮一下模型流的實現。他跟消息流很相似，首先要能被監聽，其次，還接收到消息後還要能手動產生，因此也可使用 Subject 來實現。可是這裏我用的是 BehaviorSubject ，由於 Behavior Subject 可以保留最後產生的對象，這樣咱們就能夠隨時訪問模型裏面的數據，而不須要使用 Subscribe。

$res = new BehaviorSubject<TState>(initState);

至此，1/3 的工做已經完成了，如今來按照咱們的要求，使用 rxjs 讓消息流能正確的觸發模型流的更新。

this.$msg.scan(this.update, initState)
            .subscribe((s: TState) => {
                    $res.next(s);
            });

scan 是 rxjs 的一個操做符，相似於 JS 中的 reduce，LINQ 中的 Aggregate。由於設置了一個初始模型（initState），因此在消息流每次產生新的消息的時候，update 函數就能夠接收到上一次計算出來的模型，以及最新接收到的消息，而後返回新的模型。也就是說，scan 將消息流轉化爲了新的模型流。接着訂閱這個模型流，並用以前定義的 BehaviorSubject 來廣播新的模型。

這裏就接近完成 1/2 的工做了，模型跟消息這兩個的東西已經實現好了，接下來就繼續實現更新。

Elm 是一門函數式語言，模式匹配的能力比 js 不知道高到哪裏去了，既然要模仿 Elm 架構，那麼這個地方也要仿出來。

type Pattern<TMsg, TState, TMsgType> =
    [new (...args: any[]) => TMsg, (acc: TState, msg: TMsg, $msg: Subject<TMsgType>) => TState];

    /**
     * Pattern matching syntax
     * @template TMsg
     * @param {new (...args: any[]) => TMsg} type constructor of Msg
     * @param {(acc: TState, msg: TMsg, $msg: Subject<TMsgType>) => TState} reducer method to compute new state
     * @returns {Pattern<TMsg, TState, TMsgType>}
     * @memberof ElmArch
     */
    caseOf<TMsg>(
        type: new (...args: any[]) => TMsg,
        reducer: (acc: TState, msg: TMsg, $msg: Subject<TMsgType>) => TState)
        : Pattern<TMsg, TState, TMsgType> {
        return [type, reducer];
    }

    matchWith<TMsg>($msg: Subject<TMsgType>, patterns: Pattern<TMsg, TState, TMsgType>[]) {
        return (acc: TState, msg: TMsg) => {
            const state = acc;
            for (const it of patterns) {
                if (msg instanceof it[0]) {
                    return it[1](state, msg, $msg);
                }
            }
            throw new Error('Invalid Message Type');
        };
    }

首先咱們定義了一個元組類型 Pattern 用來表示模式匹配的語法，在這裏面，主要須要實現的是基於類型的匹配，因此元組的第一個元素是消息類，第二個參數是當匹配成功時要執行的回調函數，用來計算新的模型，使用 caseOf 函數能夠建立這種元組。matchWith 函數的返回值是一個函數，與 scan 的第一個參數的簽名相符合，第一個參數是最後被建立出來的模型，第二個參數是接收到的消息。在這個函數中，咱們找到與接收到的消息相匹配的 pattern 元組，而後用這個元組的第二個元素計算出新的模型。

用上面的東西就能夠比較好的模擬模式匹配的功能了，寫出來的樣子像這樣：

const newStateAcc = matchWith(msg, [
            caseOf(GetMonth, (s, m, $m) => {
                // blablabla
            }),
            caseOf(GetMonthRecv, (s, m) => {
                // blablabla
            }),
            caseOf(ChangeDate, (s, m) => {
                // blablabla
            }),
            caseOf(SaveRecord, (s, m, $m) => {
                // blablabla
            }),
            caseOf(SaveRecordRecv, (s, m) => {
                // blablabla
            })
        ])

這樣，以前用來構建模型流的地方就須要作一些改動：

this.$msg.scan(this.matchWith(this.$msg, patterns), initState)
            .subscribe((s: TState) => {
                    $res.next(s);
            });

如今構建模型流須要依賴一個初始狀態跟一個模式數組，那麼就能夠用一個函數封裝起來，將這兩個依賴項做爲參數傳入：

begin(initState: TState, patterns: Pattern<any, TState, TMsgType>[]) {
        const $res = new BehaviorSubject<TState>(initState);
        this.$msg.scan(this.matchWith(this.$msg, patterns), initState)
            .subscribe((s: TState) => {
                    $res.next(s);
            });
        return $res;
    }

到目前爲止，2/3 的工做就已經完成了，咱們設計出了消息流、模型流以及處理消息的更新方法，作一個簡單的計數器是徹底沒有問題的。點擊查看樣例

可是實際上，咱們須要面對的問題遠不止一個計數器這麼簡單，更多的狀況是處理請求，有時候還須要處理消息的時候觸發新的消息。對於異步的請求，須要在請求的響應中觸發新的消息，能夠直接調用 $msg.next() ，對於須要在更新的操做中觸發新的消息，也能夠主動調用 $msg.next() 這個函數就行了。

不過，事情每每沒有這麼簡單，由於模型流並非從消息流直接經過 rxjs 的操做符轉換出來的，而更新函數中模式匹配部分執行時間長短不一，這可能致使消息與模型更新順序不一致的問題。我想出的解決方法是：對於同步的操做須要觸發新的消息，就必需要保證當前消息處理完成後，模型的更新被廣播出去後才能觸發新的消息。基於這一準則，我就又添加了一些代碼：

type UpdateResult<TState, TMsgType> = TState | [TState, TMsgType[]];

/**
* Generate a result of a new state with a sets of msgs, these msgs will be published after new state is published
* @param {TState} newState
* @param {...TMsgType[]} msgs
* @returns {UpdateResult<TState, TMsgType>}
* @memberof ElmArch
*/
nextWithCmds(newState: TState, ...msgs: TMsgType[]): UpdateResult<TState, TMsgType> {
    if (arguments.length === 1) {
        return newState;
    } else {
        return [newState, msgs];
    }
}

在這裏，我添加了新的類型—— UpdateResult<TState, TMsgType>，這個類型表示模型類型或模型類型與消息數組類型的元組類型。這麼提及來確實有些繞口，這個類型存在的意義就是：Update 函數除了返回新的模型以外，還能夠選擇性的返回接下來要觸發的消息。這樣，單純的模型流就變成了模型消息流，接着在 subscribe 的地方，在原先的模型流產生新的模型的地方後面再去觸發新的消息流，若是返回結果中有須要觸發的消息的話。

完整代碼在此：https://gist.github.com/ZeekoZhu/c10b30815b711db909926c172789dfd2

使用樣例

在上面的 gits 中提到了一個樣例，可是不是很完整，以後會放出完整例子。

總結

看到這裏，你可能已經發現了，本文實現的這個小工具看起來跟 redux 挺像的，確實，redux 也是 js 程序員對 Elm 架構的致敬。經過把 Web 應用的邏輯拆解成一個個狀態間改變的邏輯，能夠幫助咱們更好的理解所編寫的東西，同時，也讓 MV* 的思想獲得進一步的展示，由於在編寫 update 相關的代碼的時候，能夠在實現業務邏輯的同時而絕不碰觸 UI 層面的東西，因此，正如本文開頭提到的，視圖能夠是任何東西：React、Angular、jQuery，這都不要緊，只要可以對模型的 Observable 流的改變作出響應， DOM API 也是能夠的，可能，這就是所謂的響應式編程吧。

對於普通的 Angular 應用來講意味這什麼？

在我本身將這個小工具結合 Angular 的使用體驗來看，最大的改變就是代碼變得更加有規律了，特別是處理異步並改變 UI 的場景，變得更容易套路化，更容易套路化就意味着更方便生成代碼了。再一個，在 Angualr 中，若是組件依賴的全部輸入都是 Observable 對象，那麼能夠將默認的變動檢查策略改成：OnPush。這樣，Angular 就不用對這個組件進行「髒檢查」了，只有在 Observable 發生更新的時候，纔會去從新改變組件，這個好處，不言而喻。