問題タブ [reactjs-flux]

私は 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)。

多くのネストされた状態とコンポーネントを持つ大規模な ReactJS アプリを開発しています。ほとんどのコンポーネントを個別に独立して開発してほしいと思っています。次の 2 つのコンポーネントがあるとします。

1. 一般的な自動提案テキストボックス (たとえば、ユーザーを提案します)
2. 自動提案コンポーネントを使用するフォームコンポーネント

アプリ レベルでは、UserStore、Dispatcher、および UserActions があります。だから私の質問は

1. Auto-suggest が単独で開発されている場合、アプリ レベルの Dispatcher をどのように使用できますか? または、コンポーネントに UserStore、Dispatcher、および UserActions の別のセットが必要ですか?
2. 自動提案コンポーネントが独立して開発された場合、フォーム コンポーネントはどのように自動提案コンポーネントからデータを受け取りますか?

Flux のドキュメントには、状態をストアに格納する必要があると記載されています。次に、エンティティに関連する読み込み、保存、エラー メッセージをストアに格納する必要があります。View は Store から初期状態を取得するため、読み込み/保存が Store からのものかどうかを知る唯一の方法です。

また、フォームのユーザーが編集をキャンセルすることを決定した場合、これらの中間フォームの値はストアに送信するのではなく、ビューの状態に保存する必要がありますか?