Redux / NgRxを使用しないリアクティブアプリケーション

今日は、完全にOnPush戦略に基づいて作成されたリアクティブアングルアプリケーション（ githubリポジトリ ）を詳細に分析します。 別のアプリケーションはリアクティブフォームを使用しますが、これはエンタープライズアプリケーションでは非常に一般的です。



Flux、Redux、NgRxは使用せず、Typescript、Angular、RxJSで既に利用可能な機能を利用します。 実際、これらのツールは特効薬ではなく、単純なアプリケーションでも不必要に複雑になる可能性があります。 私たちは、Fluxの作者の1人 、Reduxの作者、NgRxの作者から、これについて正直に警告されています。



しかし、これらのツールはアプリケーションに非常に優れた機能を提供します

• 予測可能なデータフロー。
• 設計によりOnPushをサポートします。
• データの不変性、蓄積された副作用の欠如、その他の楽しいこと。

同じ特性を取得しようとしますが、複雑さを増すことはありません。



記事の終わりまでにわかるように、これは非常に簡単なタスクです。AngularとOnPushの詳細を記事から削除すると、いくつかの簡単なアイデアしかありません。



この記事では、新しい普遍的なパターンは提供していませんが、読者に、その単純さのために、何らかの理由ですぐに思いつかなかったいくつかのアイデアを共有しているだけです。 また、開発されたソリューションは、Flux / Redux / NgRxと矛盾したり置き換えたりすることはありません。 これが本当に必要な場合は、接続できます。



記事を快適に読むには、 スマート、プレゼンテーション、およびコンテナコンポーネントという用語を理解することが必要です。

アクションプラン

アプリケーションのロジックおよび資料の表示の順序は、次の手順の形式で説明できます。

1. 読み取り（GET）と書き込み（PUT / POST）に別々のデータ
2. コンテナコンポーネントにストリームとして状態をロードする
3. OnPushコンポーネントの階層に状態を配布する
4. コンポーネントの変更についてAngularに通知する
5. カプセル化されたデータ編集

OnPushを実装するには、Angularで変更検出を実行するすべての方法を解析する必要があります。 そのような方法は4つしかないため、この記事全体でそれらを順次検討していきます。



行きましょう。

読み書き用のデータを共有する

通常、アプリケーションは型付きコントラクトを使用して、フロントエンドとバックエンドの間で通信します（そうでない場合、なぜtypescriptが必要なのですか？）。



検討しているデモプロジェクトには実際のバックエンドはありませんが、事前に準備された記述ファイルswagger.jsonが含まれています。 それに基づいて、typescriptコントラクトはsw2dtsユーティリティによって生成されます。



生成されたコントラクトには2つの重要なプロパティがあります。



まず、読み取りと書き込みは異なるコントラクトを使用して実行されます。 小さな規則を使用して、接尾辞「State」の契約を読み取り、接尾辞「Model」の契約を作成することを参照します。



このように契約を分離することにより、アプリケーション内のデータフローを共有しています。 上から下に、読み取り専用の状態がコンポーネント階層を通して伝播されます。 データを変更するには、最初に状態からのデータが入力されているモデルが作成されますが、別のオブジェクトとして存在します。 編集の最後に、モデルはコマンドとしてバックエンドに送信されます。



2番目の重要な点は、すべての状態フィールドが読み取り専用修飾子でマークされていることです。 そのため、typescriptレベルで免疫力のサポートを受けています。 これで、コードの状態を誤って変更したり、[（ngModel）]を使用してコードにバインドしたりすることができなくなります。アプリケーションをAOTモードでコンパイルすると、エラーが発生します。

コンテナコンポーネントにストリームとして状態をロードする

状態をロードして初期化するには、通常の角度サービスを使用します。 彼らは次のシナリオを担当します。

• 古典的な例は、ルーターからコンポーネントによって取得されたidパラメーターを使用して、HttpClientを介してロードすることです。
• 新しいエンティティを作成するときに空の状態を初期化します。 たとえば、フィールドにデフォルト値がある場合や初期化する場合は、バックエンドから追加のデータを要求する必要があります。
• ユーザーがデータをバックエンドに変更する操作を実行した後、既にロードされた状態を再起動します。
• データの共同編集時など、プッシュ通知による状態の再起動。 この場合、サービスはローカル状態とバックエンドから取得した状態をマージします。

デモアプリケーションでは、最初の2つのシナリオを最も典型的なものと見なします。 また、これらのシナリオは単純であり、サービスを単純​​なステートレスオブジェクトとして実装でき、この特定の記事の主題ではない複雑さに気を取られることはありません。



サービスの例は、 some-entity.service.tsファイルにあります。



コンテナコンポーネントおよびロード状態でDIを介してサービスを取得することは残ります。 通常、これは次のように行われます。

route.params .pipe( pluck('id'), filter((id: any) => { return !!id; }), switchMap((id: string) => { return myFormService.get(id); }) ) .subscribe(state => { this.state = state; });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、このアプローチでは、次の2つの問題が発生します。

• 作成したサブスクリプションから手動でサブスクリプションを解除する必要があります。そうしないと、メモリリークが発生します。
• コンポーネントをOnPush戦略に切り替えると、データの読み込みに対する応答が停止します。

非同期パイプが助けになります。 彼はObservableに直接耳を傾け、必要に応じて登録を解除します。 また、非同期パイプを使用すると、AngularはObservableが新しい値を公開するたびに変更検出を自動的にトリガーします。



非同期パイプの使用例は、 some-entity.componentコンポーネントのテンプレートにあります 。



コンポーネントコードでは、繰り返しロジックをカスタムRxJSオペレーターに削除し、空の状態を作成するスクリプトを追加し、マージオペレーターで両方の状態ソースを1つのストリームにマージし、編集用のフォームを作成します。

 this.state$ = merge( route.params.pipe( switchIfNotEmpty("id", (requestId: string) => requestService.get(requestId) ) ), route.params.pipe( switchIfEmpty("id", () => requestService.getEmptyState()) ) ).pipe( tap(state => { this.form = new SomeEntityFormGroup(state); }) );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンテナコンポーネントで行う必要があるのはこれだけです。 そして、貯金箱にOnPushコンポーネントの変更検出を呼び出す最初の方法、非同期パイプを入れました。 何度も役立つでしょう。

OnPushコンポーネントの階層に状態を配布する

複雑な状態を表示する必要がある場合、小さなコンポーネントの階層を作成します。これが複雑さを処理する方法です。



原則として、コンポーネントはデータ階層に類似した階層に分割され、各コンポーネントは入力パラメーターを介して独自のデータを受け取り、テンプレートに表示します。



すべてのコンポーネントをOnPushとして実装するので、少し脱線して、それが何であるか、AngularがOnPushコンポーネントとどのように機能するかについて説明しましょう。 この資料を既に知っている場合は、セクションの最後まで自由にスクロールしてください。



アプリケーションのコンパイル中に、Angularはコンポーネントごとに特別なクラス変更検出器を生成します。これは、コンポーネントテンプレートで使用されるすべてのバインディングを「記憶」します。 実行時に、作成されたクラスは、変更検出ループごとに保存された式のチェックを開始します。 チェックの結果、式の結果が変更されたことが示された場合、Angularはコンポーネントを再描画します。



デフォルトでは、Angularはコンポーネントについて何も認識していないため、たとえばトリガーされたsetTimeoutや完了したAJAXリクエストなど、どのコンポーネントに影響するかを判断できません。 したがって、彼はアプリケーション内のすべてのイベントについて文字通りアプリケーション全体をチェックすることを余儀なくされています-単純なウィンドウスクロールでも、アプリケーションコンポーネントの階層全体の変更検出を繰り返しトリガーします。



これは、パフォーマンスの問題の潜在的な原因が存在する場所です。コンポーネントテンプレートが複雑になるほど、変更検出プログラムのチェックが難しくなります。 また、コンポーネントが多数あり、チェックが頻繁に実行される場合、変更の検出にはかなりの時間がかかります。



どうする？



コンポーネントがグローバルエフェクトに依存しない場合（ところで、この方法でコンポーネントを設計する方が良い）、内部状態は次のように決定されます。

• 入力パラメーター（ @Input ）;
• コンポーネント自体で発生したイベント（ @Output ）。

ここでは2番目のポイントを延期し、コンポーネントの状態が入力パラメーターのみに依存すると仮定します。



コンポーネントのすべての入力パラメーターが不変オブジェクトである場合、コンポーネントをOnPushとしてマークできます。 次に、変更検出を実行する前に、Angularは前回のチェック以降にコンポーネントの入力パラメーターへのリンクが変更されたかどうかをチェックします。 そして、それらが変更されていない場合、Angularはコンポーネント自体とそのすべての子コンポーネントの変更検出をスキップします。



したがって、OnPush戦略に従ってアプリケーション全体を構築する場合、パフォーマンスの問題のクラス全体を最初から排除します。



アプリケーションのStateはすでに不変であるため、不変オブジェクトは子コンポーネントの入力パラメーターにも転送されます。 つまり、子コンポーネントに対してOnPushを有効にする準備ができており、子コンポーネントは状態の変化に対応します。

たとえば、これらはreadonly-info.componentおよびnested-items.componentコンポーネントです



次に、OnPushパラダイムでコンポーネントの状態の変更を実装する方法を見てみましょう。

あなたの状態についてAngularに相談してください

プレゼンテーション状態-これらは、コンポーネントの外観に関与するパラメーターです。ロードインジケーター、要素の可視性のフラグ、または1つまたは別のアクションのユーザーへのアクセス可能性、3つのフィールドから1行に接着、ユーザーのフルネームなど。



コンポーネントの表示状態が変更されるたびに、Angularに通知して、UIに変更を表示できるようにする必要があります。



コンポーネントの状態のソースに応じて、Angularに通知する方法がいくつかあります。

入力パラメーターに基づいて計算されたプレゼンテーション状態

これが最も簡単なオプションです。 プレゼンテーション状態の計算ロジックをngOnChangesフックに配置します。 @入力パラメーターを変更すると、変更検出が自動的に開始されます。 デモでは、これはreadonly-info.componentです。

 export class ReadOnlyInfoComponent implements OnChanges { @Input() public state: Backend.SomeEntityState; public traits: ReadonlyInfoTraits; public ngOnChanges(changes: { state: SimpleChange }): void { this.traits = new ReadonlyInfoTraits(changes.state.currentValue); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてが非常に単純ですが、注意すべき点が1つあります。



コンポーネントの表示状態が複雑な場合、特に一部のフィールドが他のフィールドに基づいて計算され、入力パラメーターによっても計算される場合、コンポーネントの状態を別のクラスに入れ、不変にし、起動するたびにngOnChangesを再作成します。 デモプロジェクトの例は、 ReadonlyInfoComponentTraitsクラスです。 このアプローチを使用すると、依存データが変更されたときに同期する必要性から身を守ることができます。



同時に、検討する価値があります。おそらく、コンポーネントに含まれるロジックが多すぎるために、コンポーネントの状態が難しい可能性があります。 典型的な例は、1つのコンポーネントで、システムの操作方法が非常に異なるさまざまなユーザーの表現を適合させる試みです。

コンポーネントネイティブイベント

アプリケーションコンポーネント間の通信には、出力イベントを使用します。 これは、変更検出を実行する3番目の方法でもあります。 Angularは、コンポーネントがイベントを生成した場合、その状態が変化した可能性があると合理的に想定しています。 したがって、Angularはすべてのコンポーネント出力イベントをリッスンし、発生時に変更検出をトリガーします。



デモプロジェクトでは、完全に合成されていますが、まだ例はformSavedイベントをスローするコンポーネントsubmit-button.componentです。 コンテナコンポーネントはこのイベントをサブスクライブし、通知とともにアラートを表示します。



出力イベントは、意図した目的で使用します。つまり、変更検出をトリガーするためではなく、親コンポーネントとの通信用に作成します。 そうでなければ、何ヶ月も何年もたってから、このイベントがここの誰にとっても不必要なのかを覚えておらず、それを削除して、すべてを壊す可能性があります。

スマートコンポーネントの変更

コンポーネントの状態は、非同期サービス呼び出し、Webソケットへの接続、setIntervalを介した実行チェックなど、複雑なロジックによって決定される場合がありますが、それ以外のことはわかりません。 このようなコンポーネントは、スマートコンポーネントと呼ばれます。



一般に、コンテナコンポーネントではないアプリケーションのスマートコンポーネントが少ないほど、簡単に使用できます。 しかし、時にはあなたはそれらなしではできません。



スマートコンポーネントの状態を変更検出に関連付ける最も簡単な方法は、そのコンポーネントをObservableに変換し、既に説明した非同期パイプを使用することです。 たとえば、変更のソースがサービスコールまたはリアクティブフォームステータスである場合、これは既製のObservableです。 状態がより複雑なものから形成されている場合、 fromPromise 、 websocket 、 timer 、RxJSの構成からの間隔を使用できます。 または、 Subjectを使用して自分でストリームを生成します。

適切なオプションがない場合

すでに研究されている3つの方法のいずれも適切でない場合でも、 ChangeDetectorRefを直接使用する防弾オプションがあります。 このクラスのdetectChangesおよびmarkForCheckメソッドについて説明しています。



包括的なドキュメントがすべての質問に答えているため、その作業については詳しく説明しません。 ただし、 ChangeDetectorRefの使用は、Angularの内部キッチンであるため、自分が何をしているかを明確に理解している場合に限定する必要があります。



常に、この方法が必要になる可能性のあるいくつかのケースを見つけました。

1. 変更検出による手動作業-低レベルコンポーネントの実装で使用され、「自分が何をしているのかを明確に理解している」場合にのみ当てはまります。
2. コンポーネント間の複雑な関係-たとえば、テンプレート内のコンポーネントへのリンクを作成し、それをパラメーターとして階層または別のコンポーネント階層ブランチの上位にある別のコンポーネントに渡す必要がある場合。 複雑に聞こえますか？ そうです。 そして、変更を検出するだけでなく痛みをもたらすので、そのようなコードをリファクタリングする方が良いです。
3. Angular自体の動作の詳細-たとえば、カスタムControlValueAccessorを実装する場合、Angularによって制御値が非同期的に変更され 、変更が目的の変更検出サイクルに適用されないことがあります。

デモアプリケーションでの使用例として、最後の段落で説明した問題を解決する基本クラスOnPushControlValueAccessorがあります。 また、プロジェクトには、このクラスの継承者-custom radio-button.componentがあります。



これで、3種類すべてのコンポーネント（コンテナ、スマート、プレゼンテーション）に対して変更検出とOnPush実装オプションを実行する4つの方法すべてについて説明しました。 最終段階に進みます-リアクティブフォームでデータを編集します。

カプセル化されたデータ編集

リアクティブフォームにはいくつかの制限がありますが、これはAngularエコシステムで起こった最高のことの1つです。



まず第一に、それらは状態とうまく機能することをカプセル化し、事後対応的に変化に対応するために必要なすべてのツールを提供します。



実際、リアクティブフォームは、状態に関する作業をカプセル化する一種のミニストアです。データとステータスは無効/有効/保留中です。



このカプセル化を可能な限りサポートし、プレゼンテーションロジックとフォームのロジックを混在させないようにすることが残ります。



デモアプリケーションでは、検証、子FormGroupの作成、入力フィールドの無効化状態での作業など、作業の詳細をカプセル化するフォームの個々のクラスを見ることができます。



状態がロードされるときにコンテナコンポーネントにルートフォームを作成し、状態がリブートするたびにフォームが再作成されます。 これは前提条件ではありませんが、フォームロジックに以前のロード状態から残った累積効果がないことを確認できます。



フォーム自体の内部で、コントロールを構築し、コントロールからのデータを「移動」し、それらをStateコントラクトからModelコントラクトに変換します。 フォームの構造は、可能な限り、モデルの契約と一致します。 その結果、フォームのvalueプロパティは、バックエンドに送信するための既製のモデルを提供します。



将来、状態またはモデル構造が変更された場合、フィールドを追加/削除する必要がある場所でタイプスクリプトのコンパイルエラーが発生します。これは非常に便利です。



また、状態オブジェクトとモデルオブジェクトの構造が完全に同一である場合、typescriptで使用される構造タイピングにより、相互の無意味なマッピングを構築する必要がなくなります。



全体として、フォームロジックはコンポーネント内のプレゼンテーションロジックから分離され、アプリケーション全体のデータフローの複雑さを増すことなく「単独で」存続します。



それがほとんどすべてです。 フォームロジックをアプリケーションの残りの部分から分離できない場合の境界ケースが残っています。

1. 入力された値に応じたデータブロックの可視性など、表示状態の変更につながるフォームの変更。 フォームイベントにサブスクライブすることにより、コンポーネントに実装します。 これは、前述の不変の特性を介して行うことができます。
2. バックエンドを呼び出す非同期バリデーターが必要な場合は、コンポーネントでAsyncValidatorFnを構築し、サービスではなくフォームコンストラクターに渡します。

したがって、すべての「境界線」ロジックは、コンポーネント内の最も顕著な場所に残ります。

結論

私たちが得たものと、研究と開発のための他のポイントをまとめましょう。



まず、OnPush戦略の開発により、アプリケーションのデータフローを慎重に設計する必要があります。これは、ゲームのルールを彼ではなくAngularに指示しているためです。



この状況には2つの結果があります。



まず、アプリケーションを快適にコントロールできるという感覚が得られます。 「何らかの形で機能する」魔法はもはやありません。 アプリケーション内の任意の時点で何が起こっているかを明確に認識しています。 直観は徐々に開発されており、コードを開く前であっても、見つかったバグの理由を理解できます。



第二に、アプリケーションの設計により多くの時間を費やす必要がありますが、結果は常に最も「直接的」であり、したがって最も単純なソリューションになります。 これにより、アプリケーションが大きくなるにつれて非常に複雑なモンスターになり、開発者がこの複雑さの制御を失い、開発が神秘的な儀式に似た状況になる可能性が著しくゼロになります。



制御された複雑さと「魔法」の欠如により、たとえば周期的なデータ更新や蓄積された副作用などから発生する問題全体の可能性が減少します。 代わりに、アプリケーションが単に機能しない場合に、開発中にすでに目立つ問題に対処しています。 また、アプリケーションを単純かつ明確に機能させる必要があります。



また、パフォーマンスへの良い影響についても言及しました。 今、 profiler.timeChangeDetectionなどの非常に単純なツールを使用して、いつでもアプリケーションが良好な状態であることを確認できます。



また、今ではNgZoneを無効にしようとしないことは罪です 。 まず、これにより、アプリケーションの起動時にライブラリ全体をロードしないようにできます。 次に、アプリケーションからかなりの量の魔法を取り除きます。



これがストーリーの終わりです。



私たちは連絡します！