問題タブ [component-based]

私は Redux を初めて使用するので、自分のアプリケーションで使用したいと考えていますが、Redux 部分のアーキテクチャ/設計段階で立ち往生しています。これが私の要件と設計に関する私の推測です。

アプリケーションの詳細: AngularJS を使用した SPA。他のライブラリはng-redux、reselect、rxjsを使用しました。

コンポーネントの詳細: 大量のデータをレンダリングするための再利用可能なグリッド コンポーネント。

私の考え: グリッドのすべての内部コンポーネントが、検索、並べ替え、行、ヘッダー、セルなどの親/構成コンポーネントから独立している、プラグ アンド プレイのようなコンポーネント ベースのアーキテクチャを作成します。

1. すべてのコンポーネントには、ストアからの独自のレデューサー、アクション、セレクター、および状態のスライスのセットがあります。

2. すべてのコンポーネントには独自のレデューサーがあり、オンデマンドでプラグインできるため、それらを 1 か所に蓄積するのではなく、遅延してストアに登録する必要があります。

3. 検索、並べ替え、独自の状態を持つコンポーネントなどの一部のコンポーネントは、他のコンポーネントの状態にも影響を与える可能性があります。例: 別のコンポーネントによって処理されるグリッド データを取得するためのクエリ パラメータ (searchText、sortOrder など) の設定。

私の考え：

1. 最初のポイントについては、状態の依存スライスを提供するための再選択を検討しています。

2. 2点目として、レイジー登録にcombineReducersとreplaceReducerのどちらを使うべきか、いまだに混乱しています。状態の複数の部分にアクセスしたい場合、combineReducersは合わないと思います。

3. 3点目については、以下のアプローチを考えています。

   を。状態の複数の部分を更新する必要がある場合は、getState()を介して状態全体を渡します。このアプローチでは、Redux の不適切な使用を感じますが。

   b. コンポーネントAは、状態の一部を更新する独自のアクションを起動し、次に別のコンポーネントBに対して別のアクションを起動して、状態のスライスを更新します。このアプローチも、Redux の全体的なアイデアを壊しているように感じます。副作用の概念はここで使用できますが、使用方法はわかりません。おそらくredux-saga、redux-thunkなどです。

注: どちらのアプローチを使用しても、コンポーネントが他のコンポーネントを認識することにはなりません{ actionsToFire: ['UPDATE_B'] }。

4. アプリケーションのページ間を行き来する際に状態管理が必要ですが、ホット リロード、アクション リプレイ、またはサーバー側からのアプリケーション状態のプリフェッチは必要ありません。

5. コンポーネントは、不要になったときに状態を破棄する責任もあります。そして、状態は正規化された構造になります。

要件が奇妙に見えたり、あまり見られないように思われることはわかっていますが、そのままにしておきます。

私がすでに知っていることはほとんどありません：

1. Dan の古典的な記事のように Redux を使用する必要はありませんが、この場合は必要だと思います。

2. 私はスマート コンポーネントとダム コンポーネントについて知っています。ほとんどのコンポーネントはスマートに見える (つまり、アプリケーションの状態を認識している) かもしれませんが、それを維持したいのですが、間違っている可能性があります。

グリッド コンポーネントの図:

グリッド コンポーネント図