問題タブ [reactjs-flux]

モデルのバックボーン コレクションと、このコレクションのリスト ビューがあります。

ユーザーがチェックボックスをクリックすると、このコードが実行されます

ディスパッチャーでのこのアクション トリガー イベントsave-modelとここでの質問 - 誰がこのイベントを処理する必要がありますか?

2 つのオプションがあります。

1) コレクション

2) コレクション内の各モデルは dispathcer をリッスンする必要があります

React / Flux アプリケーションで ImmutableJS を使用しようとしています。

私の店はImmutable.Mapオブジェクトです。

どの時点で使用する必要があるか疑問に思っています.toJS()。店が.get(id)戻ってきたときでしょうか？またはコンポーネントで.get('member')？

react+flux アプリでストアの単体テストを書いています。ここでモック ディスパッチャを設定する例に従いました。単体テストは次のようになります。

item_store.coffee ファイルで、次のようにディスパッチャーに登録します。

モックされた Dispatcher がコールバックを登録することを期待していました。これは、jest にモックしないように指示した実際の item_store ファイルで発生するためです。ただ、ShopDispatcher.registerが未定義なので登録されていないのですが、なぜかよくわかりません。どんな助けでも大歓迎です。

私のアプリでは、1 つのデータに対して 2 つの ajax 呼び出しを行います。まず、 のリストを取得するために呼び出しを行いますecommerceIntegrations。それらを取得したら、それぞれの を取得できますorders。

私の現在のコードは次のようになります。

私は Facebook の Flux パターンに従おうとしていますが、これは従わないと確信しています。Flux を使用したデータのネストに関する他の SO の投稿を見ましたが、まだ理解できません。任意のポインタをいただければ幸いです。

reactで選択可能なオブジェクトの一覧を表示したい。いくつかの要素を所有するいくつかのグループを所有するリスト コンポーネントがあります。明らかに、リスト データ自体はストアに格納する必要がありますが、UI の状態 (たとえば、どの要素が選択されているか) はどうでしょうか。表向きはルート リスト要素のプロパティですが、それを要素に渡すには、チェーンに沿った各要素 (この場合は 1 つだけ - グループ) は、気にしなくてもそれを渡す必要があります。それ。また、別のプロパティを追加したい場合は、かなり冗長にチェーンに渡す必要があります。

また、カプセル化。異なるデータで複数回インスタンス化される可能性のあるコンポーネントを作成するにはどうすればよいですか?

他の言語では、リスト ポインターをチェーンに渡すだけで、子要素がそこから必要なものを何でも取得できるため、すべてがカプセル化されたままになります。流動的な方法は、ストアを子要素に渡すことでしょうか? UI 状態と永続データ用に別のストアを用意しますか?

私は ReactJS で Facebook Flux (Fluxxor を使用していますが、それほど重要ではないと思います) をいじっていますが、これまでのところ、アプリケーション内のデータ フローを操作する優れた方法だと思います。ただし、頭を悩ませていることが 1 つあります。これは単に Flex で行うべきではないことであるか、明らかな何かが欠けている可能性がありますが、なぜ私が質問しているのか...

たとえば、ログインするためのシステムを構築しています。非常に簡単です。ログイン ダイアログがポップアップ表示され、ユーザー名とパスワードを入力してボタンを押します。これは、LoginAction.login(username, password) Action Creator を呼び出します。これは、LOGIN イベントを Dispatcher に送信し、API 呼び出しをトリガーしてユーザーを認証し、資格情報が正しいことを確認します。API から成功が返された場合は、LOGIN_SUCCESS イベントを Dispatcher にトリガーします。SessionStore がこれを処理し、ログインに成功したという事実と、ユーザーの詳細を保存します。これにより、UI の一部が更新されます。たとえば、「ログイン」ボタンが「Hello Graham」というテキストに変わり、代わりに「ログアウト」ボタンが表示されます。それはすべて本当に簡単で、うまく機能し、理にかなっています。

私が立ち往生しているのは、ログインが失敗したときです。無効なユーザー名/パスワードを入力した場合、ログインダイアログでユーザーにこれを伝えて、入力した内容を修正して再試行できるようにします。これを達成するために私が考えることができる唯一の方法は、LOGIN_FAILED イベントを Dispatcher に送信することです。これは、Dialog が表示する最後のログイン エラーを格納する Store によって処理されます。ただし、これらのエラーはアプリケーションの状態ではなく、失敗したこの 1 つの要求に関する推移的な情報であるため、ユーザーが修正して再試行するため、奇妙に感じます。

この推移的な状態は、ユーザー入力が原因で失敗する可能性のある API 呼び出しの周りで非常に一般的になるので、アプリケーションの状態の一部としてではなく、別の場所に属しているように感じます。ただし、Flux がこの推移的な状態を UI に戻してユーザーに表示する方法を理解できません...

これはどちらかというと「あなたの意見はどうですか/私の考えは正しいですか?」です。質問。

Flux を理解しながら、できるだけ厳密にしようとして、XHR 呼び出しが行われる場所、Websockets/外部刺激が処理される場所、ルーティングが行われる場所などを把握しようとしました。

記事やインタビューを読んだり、Facebook の例を調べたりすると、これらのことを処理する方法がいくつかあります。PENDING/SUCCESS/FAILUREフラックスに厳密に従うと、アクション作成者は、リクエストが完了する前と完了後にアクションが発生する可能性があるすべての XHR 呼び出しを実行する人です。
もう 1 つは、Facebook の Ian Obermiller によるもので、すべての READ(GET) リクエストはストアによって直接処理され (アクション クリエーター/ディスパッチャーの関与なし)、WRITE(POST) リクエストはaction>dispatcher>storeフロー全体を通過するアクション クリエーターによって処理されます。

私たちが導き出した/固執したいいくつかの理解/結論:

1. 理想的には、システムに出入りすることはすべて、アクションを介してのみ行われます。
2. システムを出入りする非同期呼び出しにはPENDING/PROGRESS(think file uploads)/SUCCESS/FAILUREアクションがあります。
3. アプリ全体で単一のディスパッチャ。
4. Action>Dispatcher>Store呼び出しは、イベント/アクションの連鎖を避けるために内部で別のディスパッチを開始できないディスパッチに固執するために厳密に同期的です。
5. ストアはビュー間で永続化されます (単一ページのアプリであることを考えると、データを再利用できるようにする必要があります)

私たちがいくつかの結論に達したいくつかの質問ですが、私は完全に満足していません:

1. ストアが読み取りを行い、アクションが書き込みを行うアプローチを取る場合、複数のストアが単一の XHR 呼び出しからのデータを使用できる可能性がある状況をどのように処理しますか?
   例: TeamStore によって発行された API 呼び出しは、/api/teams/{id}次のようなものを返します。

   理想的には、この API で返された情報で MemberStore も更新したいと考えています。レコードの更新時に更新されるすべてのエンティティのバージョン番号を維持します。これは、古いデータの呼び出しを拒否するなどの内部で使用するものです。これを使用すると、内部ロジックを持つことができます。他の API 呼び出し、データが古いことはわかっているので、そのレコードの更新をトリガーします。
   解決策は、ストアがアクションをトリガーする必要があることです（これにより、他の依存ストアが効果的に更新されます）。これは Store>View>Action を Store>Action に短絡させますが、これが良いアイデアかどうかはわかりません。独自の XHR 呼び出しを行う Store と同期していないものが既に 1 つあります。このような譲歩は、最終的にはシステム全体に忍び込み始めるでしょう。
   または、他の店舗を認識しており、それらと通信できる店舗。しかし、これは Stores have no Setters ルールに違反しています。

   2. 上記の問題に対する簡単な解決策は、外部の着信/発信刺激が発生する唯一の場所であるアクションに固執することです。これにより、複数のストアが更新されるロジックが簡素化されます。
      しかし今、キャッシングをどこでどのように処理するのでしょうか? キャッシングは API Utils/DAO レベルで行われるという結論に達しました。（フラックスダイアグラムを見ると）。
      しかし、これは他の問題をもたらします。例で私が意味することをよりよく理解/説明するには：

      • /api/teamsすべてのチームのリストを表示するすべてのチームのリストを返します。

      • チームのリンクをクリックすると/api/teams/{id}、ストアにまだ存在しない場合にデータを必要とする詳細ビューに移動します。
        Actions がすべての XHR を処理する場合、View は which が行うようなことTeamActions.get([id])を行いTeamDAO.get([id])ます。この呼び出しをすぐに返すことができるようにするために (キャッシュされているため)、DAO はキャッシュを行う必要がありますが、コレクション/アイテム間の関係も維持する必要があります。このロジックは、設計上、既にストアに存在しています。
        ここに質問があります：

      • このロジックを DAO とストアで複製しますか?

      • DAO にストアを認識させて、既にデータがあるかどうかをストアに問い合わせて、302 というメッセージを返すことができますか。

   3. XHR API を含む検証をどのように処理しますか? 重複するチーム名のような単純なもの。
      ビューはDAOに直接ヒットしTeamDAO.validateName([name])、プロミスを返すようなことをしますか、それともアクションを作成しますか? ほとんどの一時的なデータを考慮して、有効/無効がビューに戻るアクションを作成する場合は、どのストアを経由しますか?

   4. ルーティングをどのように処理しますか? 私はreact-routerを調べましたが、それが好きかどうかわかりません。ルートマッピング/構成を提供する反応的なJSXの方法を強制する必要があるとは必ずしも思いません。また、明らかに、単一のディスパッチャ ルールを実行する独自の RouteDispatcher を採用しています。
      私が好む解決策は、ルート マッピングが RouteStore に格納されているいくつかのブログ投稿/SO 回答から得られました。
      RouteStore は CURRENT_VIEW も維持します。React AppContainer コンポーネントは RouteStore に登録され、変更時にその子ビューを CURRENT_VIEW に置き換えます。現在のビューは、それらが完全にロードされたときに AppContainer に通知し、AppContainer は RouteActions.pending/success/failure を起動し、おそらく何らかのコンテキストで、他のコンポーネントに安定状態に達したことを通知し、ビジー/ロード表示を表示/非表示にします。

   私がうまく設計できなかったのは、Gmail と同様のルーティングを設計するとしたら、どのように設計するかということでした。私が大ファンである Gmail のいくつかの観察:

   • ページをロードする準備が整うまで、URL は変更されません。「読み込み中」の間は現在の URL にとどまり、読み込みが完了すると新しい URL に移動します。これにより、...
   • 失敗しても、現在のページはまったく失われません。そのため、作成中に「送信」が失敗しても、メールを失うことはありません (つまり、現在の安定したビュー/状態を失うことはありません)。(自動保存は le pwn であるため、彼らはこれを行いませんが、アイデアはわかります) 再度送信できるようになるまで安全に保管するために、メールをどこかにコピー/貼り付けするオプションがあります。

   参考文献:
   https://github.com/gaearon/flux-react-router-example http://ianobermiller.com/blog/2014/09/15/react-and-flux-interview/ https://github. com/facebook/flux