Angular6-サービスインジェクションではなく@ngrx / storeを使用する理由

私は最近、@ ngrx / storeでAngular6を学習していますが、チュートリアルの1つは状態管理に@ ngrx / storeを使用することですが、@ ngrx / storeを舞台裏で使用する利点を理解していません。

たとえば、単純なログインおよびサインアップアクションの場合、以前はサービス（AuthServiceと呼びましょう）を使用して、バックエンドAPIを呼び出し、AuthServiceに「userInfo」または「token」を格納し、ユーザーを「HOME」にリダイレクトします。ページを開くと、DIを使用してuserInfoを取得する必要がある任意のコンポーネントにAuthServiceを挿入できます。これは、1つのファイルAuthServiceがすべてを処理するだけです。

@ ngrx / storeを使用している場合、上記のアクションまたはイベントを処理するためにおそらく4つまたは5つのファイルに書き込む必要があるAction / State / Reducer / Effects / Selectorを定義する必要がありますが、それでもバックエンドAPIを呼び出す必要がある場合がありますはるかに複雑で冗長に見えるサービスを使用しています...

他のシナリオでは、一部のページで@ ngrx / storeを使用して、オブジェクトまたはグリッドデータなどのオブジェクトのリストを格納していることもあります。、それはある種のインメモリストアの使用のためですか？

では、質問に戻りましょう。Angularプロジェクトでサービス登録ストアよりも@ ngrx / storeを使用しているのはなぜですか？ 「状態管理」用であることは知っていますが、「状態管理」とは正確には何ですか？それはトランザクションログのようなものですか、いつ必要ですか？なぜフロントエンドで管理するのでしょうか。@ ngrx / storeエリアであなたの提案や経験を自由に共有してください！

Ngrxストアに関する次の2つの投稿を読む必要があると思います。

• Angularサービスレイヤー：Redux、RxJ、Ngrxストア-ストアを使用するタイミングとその理由
• Ngrxストア-アーキテクチャガイド

最初のものがNgrxストアによって解決された主な問題を説明している場合は、React How-Toからのこのステートメントも引用しています。

フラックスが必要な時期がわかります。必要かどうかわからない場合は、必要ありません。

私にとって、Ngrxストアは複数の問題を解決します。たとえば、オブザーバブルを処理する必要がある場合や、一部のオブザーバブルデータに対する責任が異なるコンポーネント間で共有されている場合です。この場合、ストアアクションとレデューサーは、データの変更が常に「正しい方法」で実行されることを保証します。

また、httpリクエストのキャッシュに信頼できるソリューションを提供します。リクエストとそのレスポンスを保存できるので、作成しているリクエストにまだレスポンスが保存されていないことを確認できます。

2番目の投稿は、Facebookの未読メッセージカウンターの問題で、そのようなソリューションがReactの世界に登場した理由についてです。

観測不可能なデータをサービスに保存するソリューションについて。一定のデータを処理している場合は正常に機能します。ただし、複数のコンポーネントでこのデータを更新する必要がある場合は、変更検出の問題と不適切な更新の問題が発生する可能性があり、次の方法で解決できます。

• プライベートサブジェクトパブリックオブザーバブルと次の関数を持つオブザーバーパターン
• Ngrxストア

3番目のオプションもあります*ngFor="let item of userService.users"。たとえば、データをサービスに使用し、サービスをhtmlで直接使用します。したがって、userService.users追加または更新アクションがhtmlで自動的にレンダリングされた後にサービスで更新する場合、オブザーバブル、イベント、またはストアは必要ありません。

アプリのデータが複数のコンポーネントで使用されている場合は、データを共有するための何らかのサービスが必要です。これを行うには多くの方法があります。

適度に複雑なアプリは、最終的にはフロントエンドのバックエンド構造のように見え、データ処理はサービスで行われ、オブザーバブルを介してデータがコンポーネントに公開されます。

ある時点で、データサービス、データの出し入れ方法、クエリなどに何らかのAPIを書き込む必要があります。データの不変性や、データを変更するための明確に定義された単一パスなど、多くのルールがあります。サーバーバックエンドとは異なりますが、API呼び出しよりもはるかに高速で応答性が高くなります。

APIは、すでに存在する多くの状態管理ライブラリの1つのように見えます。それらは難しい問題を解決するために存在します。アプリがシンプルな場合は、それらは必要ないかもしれません。