私はReact Fluxアーキテクチャの理解について

React Fuxアーキテクチャ概要
個人は今の段階Flux構造に対して理解して、れんがをたたいてstarを求めます!原文のリンク:https://github.com/kuitos/kuitos.github.io/issues/27
Reactプロファイルはここを突いてください.
Fuxとは何ですか
Fuxは、クライアントのウェブアプリケーションを構築するためのフェイスブックのアプリケーションアーキテクチャである.これは、一方向データストリームの方式を用いて、react内のビューコンポーネントを組み合わせる.これは正式なフレームではなく、モデルのように、開発者は多くの新しいコードを必要としないで素早く手Fluxができます.
Fuxのコア部分
1.dispatcher
イベントスケジュールセンターは、fluxモデルのハブで、Fluxアプリケーションのすべてのデータストリームを管理しています.本質的にはStoreのコールバック登録です.各Storeはそれ自身を登録して、コールバック関数を提供します.DisplatchがActionに応答すると、登録済みのコールバック関数により、Actionから提供されたデータ負荷がアプリケーションのすべてのStoreに送信される.レベル別の例を適用します.
2.store
パッケージ応用の業務ロジックとデータの相互作用を担当します.

Storeには、アプリケーションのすべてのデータが含まれています.

Storeはアプリケーションで唯一のデータが変更されたところです.

Storeには、割り当てインターフェースがありません.すべてのデータの変更は、dispacherによってstoreに送信されます.新しいデータは、Storeによってトリガされたchangeイベントによってviewに伝えられます.Store外部はgetterだけを暴露して、setterを提供することを許さない!Storeはどこでも直接操作できません.

3.view

controller-viewは、一般にアプリケーションの最上位の容器として機能し、storeからデータを取得し、データをサブアセンブリに転送する役割を担うMVCモデルにおけるcontrollerとして理解され得る.簡単な応用は普通は一つのcontroller-viewだけで、複雑な応用の中にも複数があります.controller-viewはアプリケーションの中で唯一stateを操作できるところです.

view(UIコンポーネント)ui-componentの職責は単一でactionトリガ・イベントのみの呼び出しを許可し、データは上位のコンテナから属性を通して渡される.

4.その他
action creatorsはdispatcherの補助関数として、通常はFluxの第四部分と考えられています.アクションクリエーターは比較的独立しています.文法上の補助関数としてaction形式でdispatcherにデータを伝えるのがもっと便利です.
How Fux Works

view-->actionCreators

// Nav.jsx
export default class Nav extends React.Component {

  _handleClick(nav) {
    NavActionCreators.clickNav(nav);
  }

  render() {

    let itemList = this.props.list.map((nav, index) => {
      return (
        

          {nav.text}
        
      );
    });

    return (
      
    );
  }
}

action dispatch

// NavActionCreators.js
export default {

  clickNav(nav){

    AppDispatcher.dispatch(
      {
        type: ActionTypes.CLICK_NAV,
        nav
      }
    );
  }
};

dispatcher-->store calback

AppDispatcher.register(action => {

  switch (action.type) {

    // nav  
    case ActionTypes.CLICK_NAV:

      IndexWebAPIUtils.getGiftList(_currentUserInfo.userId, action.nav.id)
        .then(function (giftList) {

          _currentGiftList = giftList;
          IndexStore.emitChange();
        });

      break;

    // no default
  }
});

store emiit Change-->controller view->set State

export default class Index extends React.Component {

  constructor(props) {
    super(props);
    let currentUser = UserStore.getCurrentUser();
    this.state = IndexStore.getAll();
  }

  componentDidMount() {
    IndexStore.addChangeListener(this._onChange.bind(this));
  }

  componentWillUnmount() {
    IndexStore.removeChangeListener(this._onChange.bind(this))
  }

  _onChange() {
    this.setState(IndexStore.getAll());
  }

  render() {

    let state = this.state;

    return (
      

        ...
        
    );
  }

}

Fux vs MVM
MVVM
1.簡単なMVM
2.複雑なMVC
Fux
1.複雑なFlux
Fuxの強み
1.データの状態が安定していると同時に行動が予測できます.
アングラー双重結合の原因で、データがいつ安定しているかは永遠に分かりません.だから私たちはよくアングラーでsetTimeoutを通じていくつかの問題を処理しているのを見ます.同時に双方向結合の原因で、行動の流れも予測しにくいです.ビューのmodelが多くなると、サブビューがこれらのmodelに依存すると、問題が発生した時の位置付けは悪夢のようです.(これもアングラーのエラー情報が友好的ではない理由です.フレーム開発者も現在の行動を誰が起こしたのか確認できないからです.バインディングする人が多すぎます.)しかし、ここではやはり強調したいのですが、双方向バインディングは必ず不安定なデータ状態を招くというわけではなく、アングラーの中にはいくつかの手段によってデータを安定させることができます.ただ、双方向バインディング(mvvm)はfluxに比べてデータの不安定性を引き起こしやすいです.
2.すべてのデータ変更はstoreで行われます.
fluxでviewは直接にstoreを修正することができません.viewでできるのはactionをトリガするだけです.そしてactionはdispatcherを通じて最後にstoreに流れます.すべてのデータの変更はstoreコンポーネントの内部に発生します.storeは外部にgetインターフェースだけを提供して、set行為は内部に発生します.storeにはすべての関連データと業務ロジックが含まれます.すべてのstore関連データ処理ロジックが含まれます.の中で一緒にいて、業務のロジックが分散して維持コストを下げることを免れます.
3.データのレンダリングはトップダウンです.
viewのすべてのデータソースは属性から伝達されるべきであり、viewのすべての表現は上部制御ビュー(controller-view)によって表される.の状態によって決まります.私たちはcontroller-viewをコンテナコンポーネントとして理解できます.このコンテナコンポーネントにはいくつかの細かいサブコンポーネントが含まれています.異なる状態に応じて、異なるデータに対応しています.サブコンポーネントは自分の状態がありません.つまり、データはstoreからcontroller-viewに伝達された後、controller-viewはsetStateを通じてデータを属性の方式で上から下に伝えます.各サブにviewを渡してください.
4.view層が薄くなり、本格的なコンポーネント化
2、3の2つの理由で、view自身が必要とすることが少なくなりました.業務ロジックがstoreによって行われ、状態変更がcontroller-viewによってなされました.view自身が必要とするのは、インタラクションによって異なるactionだけです.これだけのメリットは、view層全体が薄くなり、純粋になり、完全にui層のインタラクションのみに注目して、各viewが完成する前にコンポーネントが完成されます.全部松結合で、viewコンポーネントの多重性が大幅に向上しました.
5.dispatcherは一例です.
個々のアプリケーションにとってdispatcherは一例です.最も主要なのはdispatcherはデータの配布センターです.すべてのデータはdispatcherを通じて流れる必要があります.dispatcherは異なるactionをstoreとの関係を管理します.すべてのデータはdispatcherのところに残しておく必要があります.これに基づいて多くの面白いことができます.様々なdebugツール、動作スクロール、日誌を記録します.録音や権限ブロックなどは可能です.
Fuxの苦境
1.多すぎるサンプルコード
fluxはただのアーキテクチャモードであり、既に実現されているフレームワークではないので、このモデルに基づいて、サンプルコードをたくさん書く必要があります.コード量duangが一気に上がってきました.でも、幸いにも現在はfluxに基づいて多くの第三者が実現しています.現在最も人気のあるのはreduxです.
2.dispatcherは一例です.
fluxのイベント配布センターとしてdispatcherは、すべてのstoreのイベントを管理しています.アプリケーションにおいてイベントのタイミングの管理が複雑になり、維持が難しくなり、どのstoreが管理されているかを明確に表現することができます.
3.非同期処理はどこに書いてありますか?

は、fluxフローに従って、actionで処理される:actionに依存するコンポーネントは、サービス論理

に強制的に結合される.

store職責によってstoreで処理する:store状態が不安定になり、dispatcherのwaitForが失効する

4.まだ公式に実現されていない
最後に書く

フロントエンドムーアの法則:フロントエンドは18ヶ月ごとに難易度が

倍増加します.

銀弾がありません.