5

現在、ngrx ストアを使用するように Angular アプリケーションをリファクタリングしており、2 つのオプションがあります。アプリケーションの基本構造は次のとおりです。ほとんどの Angular アプリケーションは同じように構築されていると思います。

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

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

それを解決するには、いくつかの方法があります。

  1. @Input/を使用してコンポーネント間で通信する@Output
  2. Store状態を知る必要があるコンポーネントに注入する

オプション 1 は、ドキュメントで読んだ中で最も一般的/推奨されるパターンです。したがって、ContainerComponent のみが太く、すべての子はシン/ダムであり、 を介して入ってくる状態に依存し@Inputます。

しかし、私が見たところ、このアプローチは多くのボイラープレートを追加し、状態を孫のコンポーネントに渡すためだけに不要な属性を追加する必要があります。また、中間コンポーネントは下にあるコンポーネントで何が必要かを知る必要があるため、懸念の分離の原則を破ります。また、グランド コンポーネントでしか利用できない詳細を知っていると、ジェネリック コンポーネントを作成するのは容易ではありません。

一方、アプローチ 2 は、関心の分離の問題を解決しているようであり、よりクリーンな実装でもあるようです。しかし、私はreduxパターンの使用に比較的慣れていないため、それが正しい方法であるかどうかはわかりません。おそらく、リファクタリングに深く入り込みすぎたときに直面する可能性のある落とし穴も知らないでしょう。

IMO、両方のアプローチは、私にとって非常に大きな各コンポーネントのテストの簡単な方法を提供します.

どのアプローチをとるべきか迷っています。どのような落とし穴に注意する必要がありますか?

ありがとう

4

2 に答える 2

4

Redux の作成者である Dan Abramov (ngrx は redux から着想を得ているため、多くの同じアイデアが ngrx に適用されます) は、このトピックについて次のように述べています。

コンテナを導入する時期最初にプレゼンテーション コンポーネントだけでアプリの構築を開始することをお勧めします。最終的に、中間コンポーネントにあまりにも多くの小道具を渡していることに気付くでしょう。一部のコンポーネントが受け取った props を使用せず、単にそれらを転送するだけであり、子がさらにデータを必要とするたびにすべての中間コンポーネントを再配線する必要があることに気付いた場合は、いくつかのコンテナー コンポーネントを導入するのに適した時期です。このようにして、ツリーの途中にある無関係なコンポーネントに負担をかけることなく、葉のコンポーネントにデータと動作の小道具を取得できます。これは継続的なリファクタリング プロセスであるため、最初から正しく設定しようとしないでください。このパターンを試してみると、いつコンテナを抽出するかを直感的に理解できるようになります。

ソース: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0#7dc5

于 2017-07-14T13:09:41.837 に答える