問題タブ [reactjs-flux]

ストア ライフサイクルに関する質問の補足として、

典型的な Web アプリでは、URL を介して現在のアプリケーション状態へのショートカットがあると便利です。これにより、その状態に再度アクセスし、進むボタンと戻るボタンを使用して状態間を移動できます。

Flux では、すべてのアクションがディスパッチャを通過するようにします。これには、URL の変更も含まれると思います。フラックス アプリケーション内で URL の変更をどのように管理しますか?

私は todoapp-flux の例のソースを読んでいて、TodoStore.js でこれを見ました:

1 つのプロパティの値を変更するだけでなく、なぜ facebook が 2 つのオブジェクトをマージすることを選択したのか疑問に思っていました。そうするメリットはありますか？

Facebook の Flux Architecture を使用して開発された Web アプリがあります。このページには 2 つのビューがあります。1 つは TODO アイテムのリストを表示します。2 番目のビューには、TODO アイテムのランダムなセットが表示されます。

店舗が管理する必要がある懸念事項が明らかに 2 つあります。1 つ目は、利用可能な TODO のリストです。2 つ目は、ランダムに選択された TODO アイテムのリストです。

したがってTODOStore、利用可能な TODO アイテムを管理することのみに関心を持っている がいます。loadTODOs、addTODO、deleteTODO、へのアクションがありeditTODOます。起動時に、このストアはすべての TODO アイテムをロードしません。必要な場合にのみデータベースから TODO 項目のリストを取得したい。

2店舗目はRandomTODOListStore. ランダムに選択された TODO アイテムを管理するのが役割です。を使用して、 をRandomTODOListStore介して TODO アイテムにアクセスする必要があるように思えます。TODOStoreTODOStore.getTODOItems()

これに関する問題は、前述のように、TODOStoreが起動時に TODO 項目をロードしないことです。

問題は、「が TODO 項目を既に取得したことをどのようにRandomTODOListStore保証するのか?」ということです。TODOStore.

Javascript (React JS) を使用して、左右の矢印キーをリッスンする必要があるコンポーネントを構築しています。私のコンポーネントは、画像のリストを持つカードです。画像をクリックすると表示されるのですが、左右の矢印キーを押して画像をナビゲートできるようにしたいです。

ネストされた div がたくさんあり、どれに onKeyPress リスナーを割り当てる必要があるかを把握しようとしています。現在、多くの div に割り当てられていますが、イベントが発生していません。

フラックスのチュートリアルでは、「アプリケーションの状態はストアでのみ維持されます」と書かれています。this.stateしたがって、私には、react のコントローラービューにも、 を呼び出すコールバックを介してストアとの同期が保たれているという直感に反するように思えますsetState()。

ステートフルなコントローラービュー自体をストアとして使用する方が理にかなっているのではないでしょうか? このように、「状態」という単語がアプリに表示されるのは店舗だけです。そして、すべての非ステートフル (または非ストア) ビューは のみを使用しますthis.props。

this.state基本的に、その状態を使用するビューとその状態を管理するストアがあるのはなぜですか?ビュー自体はそれを管理できないのでしょうか? this.stateそれが変数のポイントだと思いました。

Fluxxor を使用してイベント ディスパッチャを提供する React アプリケーションのテストを書いています。これを機能させるには、内部で使用され、Node 自体によって提供されるいくつかのモジュールをモックしないように Jest に指示する必要があります。

つまり、それらをunmockedModulePathPatterns構成キーに追加するだけではなく、代わりに次のようなコードを使用する必要があります。

しかし、それを置くのに役立つ場所が見つかりません。setupEnvScriptFileほとんどすべてのテストで使用するいくつかのグローバルをセットアップする がありますjestが、そのコンテキストではオブジェクトを使用できないように見えるため、そこにモックを設定することはできません。

describeちょっとした一時しのぎの手段として、Fluxxor ストアをテストするブロックの最初に呼び出す関数で上記のコードをラップしましたが、理想とはほど遠いものです。

私は React の使用方法について独自の意見を持っており、Om に触発されて独自のフレームワークを構築しています。私は Flux アーキテクチャに少し似たものを実装しており、ストアはいくつかのイベントで自分自身を更新できます。

よくわからないのは、なぜ Flux アーキテクチャでストアの依存関係が必要なのかということです。

ストアは、CQRS アーキテクチャの場合のように、特定の境界付けられたコンテキストの自己完結型のデータ ホルダーになることは想定されていませんか?

イベント システムでは、2 つの CQRS コンポーネントが同じデータを保持することになります。重複データをストアに保持しないように、ストアの依存関係を表現していますか?

ストアの依存関係が必要で、他の方法ではほとんど問題を解決できない非常に具体的な使用例を誰か思いつくことができますか? 私は自分自身を見つけることができません。

フラックスストアがデータの状態を維持するシングルトンである場合、ストアにアクセスするときにコンポーネントが setProps ではなく setState を使用するのはなぜですか? アプリケーションの状態を 2 つ (またはそれ以上) の場所に保存し始めたということではないでしょうか?

Flux / React のドキュメントと例の両方で、推奨される解決策として setState が示されているようですが、職場の数人の同僚と興味深い会話をして、他の誰かがこれに出くわしたのではないかと思いました。

編集: この URL で私が話していることを確認できます: https://github.com/facebook/flux/blob/master/examples/flux-chat/js/components/ThreadSection.react.js

ThreadSection が子コンポーネントであり、ストアから直接データをフェッチし、それを状態として使用していることに注意してください。

React の「方法」に従えば、子コンポーネントではなく、状態がストアによって管理されることを期待していたでしょう。

私たちが考えた解決策は、最上位コンポーネントのすべてのストアを (props として) 取得し、必要に応じてそれらを子コンポーネントに渡すことです。しかし、それはすぐにかなり醜くなります。

setProps は子コンポーネントでは機能しないため、これを行います

ストアが独自の状態を維持し、その際にネットワークおよびデータ ストレージ サービスを呼び出す機能を備えている必要があります...その場合、アクションは単なるメッセージ パサーです。

-また-

...ストアは、アクションからの不変データの愚かな受信者であるべきですか (そして、アクションは外部ソース間でデータをフェッチ/送信するものである必要がありますか?このインスタンスのストアはビューモデルとして機能し、それらを集約/フィルタリングできますアクションによって供給された不変データに基づいて、独自の状態ベースを設定する前のデータ。

それは（両方の混合ではなく）どちらか一方であるべきだと私には思えます。もしそうなら、なぜ一方が他方よりも好まれる/推奨されるのですか?

Flux を使用するようにアプリを書き直していますが、ストアからのデータの取得に問題があります。たくさんのコンポーネントがあり、それらはたくさん入れ子になっています。大きいもの ( Article) もあれば、小さくてシンプルなもの ( UserAvatar、UserLink) もあります。

コンポーネント階層のどこでストアからデータを読み取る必要があるかで苦労しています。
私は 2 つの極端なアプローチを試みましたが、どちらもあまり好きではありませんでした。

すべてのエンティティ コンポーネントが独自のデータを読み取ります

Store からのデータを必要とする各コンポーネントは、エンティティ ID だけを受け取り、独自にエンティティを取得します。
たとえば、Articleis passed articleId、UserAvatarおよびUserLinkare passeduserIdです。

このアプローチには、いくつかの重大な欠点があります (コード サンプルで説明します)。

このアプローチの欠点:

• 何百ものコンポーネントがストアにサブスクライブする可能性があるのはイライラします。
• 各コンポーネントが個別にデータを取得するため、データがどのように更新され、どのような順序で更新されるかを追跡することは困難です。
• 状態のエンティティが既にある場合でも、その ID を子に渡す必要があり、子はエンティティを再度取得します (または、一貫性を破ります)。

すべてのデータは最上位で一度読み取られ、コンポーネントに渡されます

バグの追跡にうんざりしていたとき、すべてのデータ取得を最上位にしようとしました。ただし、エンティティによっては複数レベルのネストがあるため、これは不可能であることが判明しました。

例えば：

• Aには、そのカテゴリに貢献する s 人の人がCategory含まれます。UserAvatar
• AnArticleには複数Categoryの が含まれる場合があります。

したがって、ストアから のレベルですべてのデータを取得する場合はArticle、次のようにする必要があります。

• から記事を取得しArticleStoreます。
• からすべての記事のカテゴリを取得しCategoryStoreます。
• から各カテゴリの貢献者を個別に取得しますUserStore。
• どういうわけか、そのすべてのデータをコンポーネントに渡します。

さらに苛立たしいことに、深くネストされたエンティティが必要な場合は常に、ネストの各レベルにコードを追加して、それをさらに渡す必要があります。

まとめ

どちらのアプローチにも欠陥があるようです。この問題を最もエレガントに解決するにはどうすればよいですか?

私の目的:

• ストアには、非常識な数の加入者がいるべきではありません。親コンポーネントがすでにそれを行っている場合、それぞれUserLinkがリッスンするのはばかげています。UserStore

• 親コンポーネントがストアから何らかのオブジェクトを取得した場合 (例: user)、ネストされたコンポーネントがそれを再度取得する必要はありません。私は小道具を介してそれを渡すことができるはずです。

• リレーションシップの追加や削除が複雑になるため、すべてのエンティティ (リレーションシップを含む) をトップ レベルでフェッチする必要はありません。ネストされたエンティティが新しい関係を取得するたびに、すべてのネスト レベルで新しい props を導入したくありません (たとえば、カテゴリが を取得しますcurator)。