FLUXの使用について

要旨:本明細書に示すサンプルコードは、JQueryコードでもReactコードでもなく、両者の間に介在し、行文擬似コードを容易にするものである.コードの意味はコンテキストで理解できる.
FacebookのJing Chenさんは2014年のF 8でFLUXアーキテクチャを実証した.FLUXのワークフローは次のとおりです.

中央Dispatcherは、入ってきたすべてのACTIONを管理する.

は、任意の複数のStore処理ACTIONを登録することができる.

コンポーネントは、データの修正が必要なときにACTIONを発行する.

しかし、上記のような簡単な言葉だけでは、なんとも言えません.例えば、私がTodoListを持っていて、itemの追加をクリックしたときに、サーバにコンテンツを送信し、サーバが返した結果に基づいて成功または失敗の結果を表示する必要がある場合、FLUXを採用すると、次のように書かれています.

javascript
dispatcher.register(function(payload){
    switch(payload.actionType) {
        case "ADD_ITEM":
            ajax("/add/item", payload.data, function success(res){
                dispatcher.dispatch("ADD_SUCCESS", payload.data);
            }, function failure(){
                dispatcher.dispatch("ADD_FAIL", payload.data);
            });
            break;
        case "ADD_SUCESS":
            // do something
            break;
        case "ADD_FAIL"
            // do something
            break;
    }
});

//       
$("#add").click(function(){
    dispatcher.dispatch({
        actionType: "ADD_ITEM",
        data: $("input").val()
    });
});

上記のコードには問題があります.Storeで非同期要求を発行し、コールバックでACTIONを発行する場合、Nested Updateに属し、問題があります.

あなたが出したactionがいつ処理されるか分からない.

あなたはあなたの事件を知らないで、データの流れはどこにありますか

は、ループ呼び出し

を容易に開始する.
もちろん、最も最終的な結果は、メンテナンスが難しいことです.
したがって、FLUXにおいて最も重要な原則は、
STOREコード同期化
上のコードは次のように変更できます.

dispatcher.register(function(payload){
    switch(payload.actionType) {
        case "ADD_ITEM":
            //      ，  "    "
            break;
        case "ADD_SUCESS":
            //       
            break;
        case "ADD_FAIL"
            //       
            break;
    }
});

$("#add").click(function(){
    var msg = $("input").val();
    dispatcher.dispatch({
        actionType:"ADD_ITEM", 
        data: msg
    });

    ajax('add/item', msg, function success(res) {
        dispatcher.dispatch({
            actionType:"ADD_SUCESS",
            data: res
        });
    }, fail(res){
        dispatcher.dispatch({
            actionType:"ADD_FAIL"
            data: res
        });
    });

});

このようにstoreの3つのcaseでの操作は同期されています.すなわち、どのactionでも、トリガした後、具体的に何が起こったのかよく分かります.
注意:上のコードのコメントに惑わされないでください.StoreはDOMを操作するべきではありません.上のコメントは、その後何が起こったのかを説明しています.
上記の例では、ajaxリクエストをコンポーネントに配置し、成功したときにactionをトリガし、失敗したときにもう1つをトリガし、プログラムの動作が完全に予測可能になります.しかし、このajaxリクエストのデータが非常に複雑であれば、コンポーネント内でリクエストを発行することはできません.これらのデータを収集する能力がないからです.
例を挙げると、ショッピングカートのページで、ある商品を追加/削除するチェックを入れます.

商品リストが

に変更されました

他のすべてのチェックされた商品および数量を収集する

ajaxをバックグラウンドに送信し、総価格(なぜかと聞かないでください.ここでは大量の満減、積分、立減などの碧池論理に関連しています)

を計算します.

バックグラウンドは、計算後の合計価格

を返す.

更新フロントエンド

上の重要なステップ ajaxはバックグラウンドに着いて、私たちは商品の数量のコンポーネントの中で送信することができなくて、単一のコンポーネントが商品のリスト全体の情報を収集することができないため、もしそれが収集することができるならば、あなたのプログラムはメンテナンスしにくくて、あなたのコンポーネントが外部の情報に強く依存するためです.
この場合、storeには対応する情報があるので、storeでデータを収集し、ajaxを発行します.△また、コンポーネントがStoreからデータを取り出せば、必要なデータが収集できるのではないかと提案する同級生もいます.FLUXのもう一つの原則は、
コンポーネントをStoreに強く依存させないでください.コンポーネントのデータはStoreではなく親コンポーネントから来るべきです.Storeに強く依存した結果、*あなたのコンポーネントは多重化しにくい*あなたのコンポーネントはテストしにくい
この例では、親コンポーネントを介してサブコンポーネントにコールバックする処理を考えることができます.

//     

    




//     
input.on('change', function(){
    //   action，       store    action
    //              
    dispatch.dispatch({
        actionType: "CHANGE_QUANTITY",
        id: this.id,
        quantity: this.value
    });
    //         onChange  
    this.props.onChange();
});

このように、1つはStore内のコードの同期化を維持することができ、2つはコンポーネント内の外部世界に対する無知を維持することができる.
FLUXの他に最も重要な特徴は、非常に拡張しやすいことです.例えば、上記のカートの例では、各商品の数を表示するブロックを追加する場合は、既存のコードを変更する必要はありません.storeを追加するだけでいいです.

dispatcher.register(function(payload) {
     switch(payload.actionType){
         case "CHANGE_QUANTITY":
             // 1.          
             // 2. update   model，  view
             break;
     }
});

【完】