angular 1.xxプロジェクトに取り組んでおり、コードをangular 2にアップグレードすることを考えています。
現在、私のプロジェクトには、データをjs配列（キャッシュとストレージの両方）にほとんど保持し、配列を処理するためにアンダースコアを使用してこれらのデータを処理するデータを処理するための多くのサービス（ファクトリー）があります。
ngrx を使用した angular2 の多くの例を見つけました。
ストア比較を使用してデータ サービスを使用してデータを処理する利点は何ですか?
複数のデータ タイプ (在庫、注文、顧客など) がある場合、アプリに複数のストアが必要ですか?
このような複数のデータ型を処理するようにアプリを構成 (設計) するにはどうすればよいですか?
あなたの質問は主に意見に基づいていますが、ngrx が適切な選択である理由をいくつか説明できます。アプリケーションのすべての状態を 1 つのオブジェクト (Single State Tree) に格納するのは得策ではないと言う人もいますが、ただし、私の意見では、あなたの状態は関係なく存在します。ストアを使用すると、すべてが一度にまとめられ、変更は明示的で追跡されますが、全体に散らばり、コンポーネントによってローカルに維持されます。さらに、アプリケーション内のストアから特定のプロパティを選択するため、関心のあるデータのみを選択できます。たとえば、常に配列を返し、Observables を使用することでレデューサーの不変性を受け入れる場合は、 ChangeDetectionStrategy を利用できますOnPush。OnPushパフォーマンスを大幅に向上させます。Angular の公式ドキュメントから抜粋した次の図を見てみましょう。
ご覧のとおり、Angular アプリはコンポーネント アーキテクチャを使用して構築され、コンポーネント ツリーが作成されます。OnPushコンポーネントの on は、入力属性が変更された場合にのみ変更検出が開始されることを意味します。たとえば、Child BisOnPushとChild Aisの内部でDefault何かを変更した場合、入力属性が変更されていないため、変更検出器はトリガーされません。ただし、内部で何かを変更すると、デフォルトの変更検出機能があるため、再レンダリングされます。Child AChild BChild BChild A
パフォーマンスと単一の状態ツリーについては以上です。ストアのもう 1 つの利点は、コードと状態の変更について実際に推論できることです。したがって、ほとんどの Angular 1.x アプリの現実はスコープ スープです。これは、 Lukas Ruebbelke によるブログ投稿からの素晴らしいグラフィックです。
写真はそれがかなり良いことを示しています。Tero Parviainenの別の記事ng-controllerでは、 . それはすべてスコープ スープに関連しており、常に変化する状態を管理することは困難です。redux動機は次のように述べていますここを参照してください：
モデルが別のモデルを更新できる場合、ビューは別のモデルを更新するモデルを更新でき、これにより別のビューが更新される可能性があります。ある時点で、アプリの状態がいつ、なぜ、どのように制御できなくなったため、アプリで何が起こっているのか理解できなくなります。システムが不透明で非決定論的である場合、バグを再現したり、新しい機能を追加したりすることは困難です。
ngrx/store を使用すると、アプリで明確なデータ フローが得られるため、実際にこの問題を回避できます。
ngrx は redux に大いに影響を受けているため、同じ主な原則が適用されると言えます。
したがって、私の意見では、最大の利点は、アクションをディスパッチし、それらが常に 1 つの場所につながるため、ユーザーのやり取りを簡単に追跡し、状態の変化について推論できることです。単純なモデルでは、すべての参照を見つけて、何が何を変更し、何が変化するかを確認する必要があります。いつ。
ngrx/store を使用すると、devtoolsを使用して状態コンテナーのデバッグを確認し、変更を元に戻すこともできます。タイムトラベルが redux の主な理由の 1 つであったと思いますが、単純な古いモデルを使用している場合、これはかなり困難です。
@muetzerich が既に述べたように、テスト容易性も ngrx/store を使用する利点です。レデューサーは純粋な関数であり、これらの関数は簡単にテストできます。入力を受け取り、単に出力を返し、関数の外部のプロパティに依存せず、http 呼び出しなどの副作用がないためです。
要するに、これらのことを行うために ngrx/store を使用する必要はありませんが、共通のパターンを提供し、優れた利点をもたらす制限 (上記の 3 つの原則) に縛られることになります。 .
あなたの質問に:
複数のデータ タイプ (在庫、注文、顧客など) がある場合、アプリに複数のストアが必要ですか?
いいえ、複数の店舗を利用することはお勧めしません。
このような複数のデータ型を処理するようにアプリを構成 (設計) するにはどうすればよいですか?
おそらく、Tero Parviainen によるこのブログ投稿は、ストアの設計方法を理解するのに役立ちます。彼は、サンプル アプリのアプリケーション状態ツリーを設計する方法を説明しています。
そこのドキュメントで見つけることができるストアを使用する利点についての素晴らしい説明
一元化された不変の状態
関連するアプリケーションの状態はすべて 1 つの場所に存在します。これにより、エラー発生時の状態のスナップショットから重要な洞察が得られ、問題の再現が容易になるため、問題の追跡が容易になります。また、これにより、Store アプリケーションのコンテキストで元に戻す/やり直しなどの難しい問題が簡単になり、強力なツールを使用できるようになります。
パフォーマンス
状態はアプリケーションの最上位に集中しているため、データの更新は、ストアのスライスに依存するコンポーネントを介して下に流れる可能性があります。Angular 2 は、このようなデータフロー配置を最適化するように構築されており、コンポーネントが新しい値を発行していない Observables に依存している場合、変更検出を無効にすることができます。最適なストア ソリューションでは、これがコンポーネントの大部分になります。
テスト容易性
すべての状態の更新は、純粋な関数であるレデューサーで処理されます。純粋な関数は、単純に入力され、出力に対してアサートされるため、テストが非常に簡単です。これにより、モック、スパイ、またはテストを複雑にしてエラーを起こしやすくするその他のトリックを使用せずに、アプリケーションの最も重要な側面をテストできます。
複数店舗？
IMO は 1 つのストアを使用し、データ型をプロパティとしてストアに追加します。
ngrx.store は、適切に設計されたコンポーネント/サービスが行うことを行い、追加の利点をもたらします。これまでのところ、これがどのようにまとめられるかについて早い段階で取り組んでいます。これが私が見つけたものです。
サービスとコンポーネントで保守不可能な混乱が発生するのは非常に簡単です。カスケード アクション、複雑なデータ インタラクション、リモート ロケーションへの呼び出しがある場合、ngrx のアクション - リデューサー - ストアの配置とほぼ同じサービスを構築することになります。小さな純粋な関数、オブザーバブルなど。ngrx には既にそれがあります。それを使用して、それが表す思考やパターンから得てみませんか。
小さなテスト可能な機能での思考を強制/奨励する場合. 適度に複雑なコンポーネントに 1 つまたは複数のレデューサーを配置すると、時間のかかる多くの落とし穴を取り除く規律が強制されます。コールバック キューに起因する準マルチスレッド競合状態を追跡することほど、時間を無駄にするものはありません。これはレデューサーで発生する可能性があると確信していますが、デバッグのために呼び出しシーケンスと状態へのアクセスが簡素化されます。
Angular2 パターンがより簡単になります。表示ロジックを備えたテンプレート、テンプレートに必要なすべての要素が集まる場所としてのコンポーネント。サービスは、リモート呼び出しを行うか、どこから来たデータの io も処理するだけなので、よりシンプルになります。次に、状態を維持および変更するためのアクションとレデューサー。これにより、他のすべてのパーツが新しい状態に応答するようになります。コンポーネント/サービス パターンでは、いずれかが大きく複雑になり、デバッグが非常に困難になるという副作用があることがわかりました。私のサービスは最終的に状態を保存し、データを処理していました。
オブザーバブル。rxjs.store ではすべてが観察可能であり、それがレスポンシブ アプリの基礎となります。アプリの状態をオブザーバブルとして構造化することは、少し難解であったり、あまり単純ではなかったりする場合がありますが、それを理解してうまく実行することで、将来的に大きな成果が得られます。
私が見ることができる唯一の欠点は、レデューサーが非常に急速に非常に大きくなることです。名前の違う同じコードが繰り返されたり、繰り返されたりする状況がたくさんあるようです。私の脳は「パラメーター付きの関数」と叫びますが、そのようには機能しません。一方で、ここはアプリの構造や状態が細かく表現されているところなので、そこにはきっとたくさんあると思います。また、何か問題が発生した場合は、問題の原因として純粋な関数を使用することで、追跡と修正が容易になります。