子コンポーネントのNGRXと状態管理

Question

現在、リファクタリングngrxストアを使用する角度アプリケーションには2つのオプションがあります。ここでは、アプリケーションの基本的な構造について説明します。私はほとんど角度のアプリケーションが同じように構築されていると信じている：

AppComponent 
|-- ContainerComponent 
    |-- ChildComponent1 
    | |-- GrandChildComponent 
    |  |-- GrandGrandChildComponent 
    |-- ChildComponent2 

ContainerComponentがStore<AppState>を注入しました。私が解決しようとしている問題は、GrandGrandChildComponent（DropDownMenuコンポーネント）がアプリケーションの状態に基づいて動作を変更しなければならないということです（つまり、ストアで発生する特定の条件でいくつかのメニュー項目を無効にします）メニュー項目の上にあるContainerComponent（または他のコンポーネント、必要な祖先ではない）がそれに反応する可能性があります。

それを解決するためのいくつかの方法があります。

1. は状態

オプション1が何であるかを知る必要が任意のコンポーネントに注入Store@Input/@Output

を使用してコンポーネント間の通信私がドキュメントで読んだ最も一般的な/推奨されるパターン。だから、ContainerComponentだけが太っていて、すべての子は薄い/愚かであり、@Inputから来る状態に依存しています。

しかし、このアプローチでは、グランドの子コンポーネントに状態をパススルーするために不必要な属性を追加する必要がある多くの定型文が追加されています。また、中間コンポーネントは、下にあるコンポーネントで必要なものを知る必要があるため、懸念の原理の分離を解除します。 Grandコンポーネントでのみ利用可能な詳細を知っている場合、ジェネリックコンポーネントを作成するのは簡単ではありません。

一方、アプローチ2は、懸念を分離する問題を解決すると思われ、よりクリーンな実装と思われます。しかし、私は比較的新しいreduxパターンを使用しているので、それは行く方法とおそらく私はリファクタリングで深くなるだろうときに直面する可能性のある落とし穴を知りませんかわからない。

IMOのどちらの方法でも、それぞれのコンポーネントを簡単にテストすることができます。

私はどちらのアプローチをとるべきか疑問に思っています。どんな落とし穴に気づくべきですか？

おかげ

Answer 1

はここでReduxののダン・アブラモフ監督の作成者は、（ngrxはReduxのため、同じアイデアの多くはngrxに適用さからインスピレーションを得て）何話題に述べている：

紹介しますコンテナ？まず、プレゼンテーションコンポーネントだけを使用して、まず というアプリの構築を開始することをおすすめします。結局、 は、あまりにも多くの小道具を中間のコンポーネントに渡していることに気付くでしょう。 一部のコンポーネントでは、 を受け取ったプロンプトを使用せず、それらを転送するだけで、子供たちがさらにデータを必要とする場合は、 中間コンポーネントをすべて再配線する必要があります。このようにして、 のデータとビヘイビアの小道具をリーフコンポーネントに得ることができます。 ツリーの途中に無関係のコンポーネントを負担させません。これは リファクタリングの進行中のプロセスなので、最初に を正しく取得しようとしないでください。このパターンを試してみると、いくつかのコンテナを抽出するときには という直感的な意味があります。ちょうどそのときに関数を抽出する時間がわかっていれば です。

出典： https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0#7dc5

Answer 2

これは、彼らが持っているどのように多くの@outputと@Inputかどうか、各コンポーネントのためのあなたのユースケースにかなり依存しています。

私はあなたの1stアプローチをかなり使用していますが、子供/下位コンポーネントが非常に簡単なやり取り（データをトップダウンしてからParentに戻す）をしたり、ダムコンポーネント（入力のみ）私のコンテナが非常に大きかったことを確認してください

しかし、あなたの子コンポーネントのうちの1つが多くのI/Oを持っていて、同じものを持つ多くの他の子/子コンポーネントを持っていたら、それらをBig-Child子の@Output（）はGrandParentコンポーネントに渡されるのではなくBig-Childコンポーネントにとどまります。

ボトムアップから@Output（）をあまりにも多く使うと、頭痛を与えるかもしれません:)。 2番目の方法は、コンポーネントを読みやすくします。

AppComponent |-- ContainerComponent |-- ChildComponent1 | |-- GrandChildComponent | |-- GrandGrandChildComponent |-- ChildComponentWithManyIO => Make them to be self-managed |--GrandChild with only Input |--GrandChild with many Inputs/Outputs (Self-managed)

状態を管理するための私の考えはここから来た：https://www.youtube.com/watch?v=eBLTz8QRg4Q