web-dev-qa-db-ja.com

フラックスのベストプラクティス：ディスパッチアクションを格納します。AJAX Web API Utilsでの呼び出し？

enter image description here

このイメージは、すべてではないにしても、ほとんどのFluxプログラマーの究極のガイドであると理解しています。このフローを念頭に置いて、いくつか質問があります。

  1. 私の$.ajax私の内部の呼び出しWeb API Utils？
    • コールバックはアクションクリエーターを呼び出し、プロセスにデータを渡します
  2. StoreでAJAX呼び出しを作成する場合、最初にAction Creatorを呼び出す必要がありますか？ Web API Utilsの関数をStoreから直接呼び出すのは根本的に間違っていますか？
  3. StoreからAction Creators？に接続する仮想の片側矢印のようなものはありますか
    • 私はビューを通過しない操作がたくさんあります
  4. コールバックDispatcherとStoreの間にあるものは何ですか？
  5. Web APIここは何ですか？これはRESTful APIを適用する場所ですか？この例はどこかにありますか？

  6. 私のAction Creatorsのいずれかにロジックを含めることはできますか（どのActionをディスパッチするかを知るため）？基本的に、このアクションはmy AJAX呼び出しからの応答を受け取ります。これはスニペットです。

    var TransportActions = {
    receiveProxyMessage: function (message, status, xhr) {
        switch (message) {
            case ProxyResponses.AUTHORIZED:
                AppDispatcher.dispatch({
                    type: ActionTypes.LOGIN_SUCCESS,
                    reply: m
                });
                break;
            case ProxyResponses.UNAUTHORIZED:
                AppDispatcher.dispatch({
                    type: ActionTypes.LOGIN_FAIL,
                    reply: m
                });
                break;
            ...
        }
    }
}

私はオンラインでさまざまな回答を見てきましたが、それらをすべてアプリケーションにどのように組み込むかはまだわかりません。ティア！

javascriptajaxreactjsreactjs-fluxflux
37
ton

すべての$ .ajax呼び出しをWeb API Utils内に含めることは正しいですか？コールバックは、アクションクリエーターを呼び出して、プロセスにデータを渡します。

はい、すべてのリクエストを単一のエンティティ、つまりWeb API Utilsに配置する必要があります。すべてのストアがそれらに基づいて行動することを選択できるように、彼らは応答をディスパッチする必要があります。

しばらく前に、リクエストを処理する方法に関する1つの方法を示すブログ投稿を書きました http://www.code-experience.com/async-requests-with-react-js-and-flux-revisited/

StoreでAJAXを呼び出す場合、Action Creatorを最初に呼び出す必要がありますか？Web API Utilsの関数をStoreから直接呼び出すことは根本的に間違っていますか？

これは良い質問であり、私が見た限りでは、誰もが少し違うことをしています。 Flux（Facebookから）は完全な答えを提供しません。

一般的に、ここで取ることができる2つのアプローチがあります。

  1. ストアはデータを「要求」するのではなく、単にアクションをダイジェストしてビューに通知するという主張をすることができます。これは、ストアが空の場合、コンポーネント内で「フェッチ」アクションを起動する必要があることを意味します。つまり、データを取得する必要がある場合は、すべてのデータリスニングビューをチェックする必要があります。複数のビューが同じストアをリッスンしている場合、これによりコードの重複が発生する可能性があります。

  2. ストアは、データを要求された場合、実際に配信する状態があるかどうかをチェックするという意味で「スマート」です。そうでない場合、API Utilsにデータをフェッチし、ビューに保留状態を返すように指示します。

    これは「APIにデータを取得するよう伝える」はコールバックベースの操作ではなく、「発射して忘れる」操作であることに注意してください。 APIは、リクエストが返されるとアクションをディスパッチします。

私はオプション1よりもオプション2の方が好きです。Facebookチームのビル・フィッシャーは、同様にこうしていると言っています。 （上記のブログ投稿のどこかのコメントを参照）

だからNo私の意見では、ストアから直接Apiを呼び出すことは根本的に間違っていません。

StoreからAction Creatorsに接続する仮想の片側矢印のようなものはありますか？

Fluxの実装に依存します。

DispatcherとStoreの間のコールバックとは何ですか？

これらは、ストア内の状態を実際に変更できる唯一の関数です！各ストアはコールバックをDispatcherに登録します。すべてのコールバックは、アクションがディスパッチされるたびに呼び出されます。各コールバックは、アクションタイプを指定してストアを変更する必要があるかどうかを決定します。一部のFluxライブラリは、この実装の詳細を隠そうとします。

ここにあるWeb APIとは何ですか？これはRESTful APIを適用する場所ですか？この例はどこかにありますか？

写真では、Web APIの四角形は実際のサーバーを表し、API Utilsはサーバーを呼び出すもの（つまり、$。ajaxまたはスーパーエージェント）であると思います。 JSONを提供するRESTful APIである可能性はほとんどありません。

一般的なアドバイス：

フラックスは非常に緩やかな概念であり、正確な実装はチームごとに変わります。 Facebookは、時間の経過とともにあちこちでいくつかのアプローチを変えていることに気付きました。正確なサイクルは厳密には定義されていません。ただし、かなり「修正された」ものがいくつかあります。

  1. すべてのアクションをすべてのストアにディスパッチし、一度に1つのアクションのみを許可してイベントチェーンの地獄を防ぐDispatcherがあります。
  2. ストアはアクションレシーバーであり、アクションを通じてすべての状態を変更する必要があります。
  3. アクションは「発射して忘れる」（コールバックなし！）
  4. ビューはストアから状態を受け取り、アクションを起動します

他のことは実装ごとに異なる方法で行われます

33
Retozi
  1. すべての$ .ajax呼び出しをWeb API Utils内に含めることは正しいですか？コールバックは、アクションクリエーターを呼び出して、プロセスにデータを渡します。

絶対に。

  1. StoreでAJAXを呼び出す場合、Action Creatorを最初に呼び出す必要がありますか？Web API Utilsの関数をStoreから直接呼び出すことは根本的に間違っていますか？

まず、ストアでAPI呼び出しを行う必要がある理由を自問してください。考えられる唯一の理由は、受信したデータをストアにキャッシュすることです（これを行います）。

最も単純なFlux実装では、すべてのアクションはビューとサーバーのみから作成されます。たとえば、ユーザーが「プロファイル」ビューにアクセスし、ビューがprofileRequestアクションクリエーターを呼び出し、ApiUtilsが呼び出され、データが入力され、ServerActionが作成され、 ProfileStoreはそれ自体を更新し、ProfileViewはそれに応じて更新します。

キャッシングの場合：ProfileViewはProfileStoreにプロファイルを要求しますが、ストアにはそれがないため、状態 'loading'の空のオブジェクトを返し、ApiUtilsを呼び出してそのプロファイルを取得します（それを忘れます）。呼び出しが終了すると、ServerActionが作成され、ProfileStoreが更新されます。これは正常に機能します。また、ストアからActionCreatorを呼び出すこともできますが、その利点はわかりません。

MartyJS は同様のことを行います。一部のフラックス実装では、Promiseで同じことを行います。

重要な部分は、データがシステムに戻ってくると、ServerActionCreatorが新しいデータで呼び出されることだと思います。その後、これはストアに戻ります。

ストアはデータのみを照会し、状態を変更するすべてのアクション（更新するもの）はユーザーが開始する（ビューから来る）必要があると思います。 Facebookのエンジニアは、これについて次のように書いています。 https://news.ycombinator.com/item?id=7719957

  1. StoreからAction Creatorsに接続する仮想の片側矢印のようなものはありますか？

店舗をスマートにしたい場合：はい。アプリをシンプルにしたい場合：いいえ、ビューを確認します。

  1. DispatcherとStoreの間のコールバックとは何ですか？

これらは、ストアで見つけるディスパッチハンドラです。ディスパッチャーはアクションを起動し、この起動イベントをリッスンし、アクション/ペイロードで何かを行います。

  1. ここにあるWeb APIとは何ですか？これはRESTful APIを適用する場所ですか？この例はどこかにありますか？

これが、ajax呼び出しの行き先です。通常、これはいくつかのREST APIを意味しますが、ウェブソケットなどでもかまいません。私はこのチュートリアルが大好きです。 http://fancypixel.github.io/blog/2015/01/29/react-plus-flux-backed-by-Rails-api-part-2 /

免責事項：これらはフラックスの私の解釈です。 Flux自体はデータの取得を実際には解決しません。そのため、FBで Relay and GraphQL を考え出しました。

5
RoryKoehein