ペースの速い Web 開発の世界では、アプリケーションの成功にはパフォーマンスとユーザー エクスペリエンスが不可欠です。 Angular 19 で、Angular チームは、増分ハイドレーションという革新的な機能を導入しました。この新しい機能により、既存のハイドレーション プロセスが強化され、開発者はコンポーネントの読み込みと対話性を正確に最適化できるようになります。この記事では、増分水分補給とは何か、その実装、さまざまなシナリオで使用する水分補給トリガーの詳細な分析について詳しく説明します。
ハイドレーションは、サーバー側でレンダリングされたアプリケーションをクライアント側でアクティブ化するプロセスです。これには、サーバーでレンダリングされた DOM 要素の再利用、アプリケーションの状態の維持、サーバーによってすでに取得されたデータの転送が必要になります。基本的に、ハイドレーションにより DOM を完全に再レンダリングする必要がなくなり、Core Web Vitals (CWV) などのパフォーマンス指標が向上します。
Angular 19 では、増分ハイドレーションが導入されました。これにより、開発者はユーザー インタラクション、可視性、またはカスタム条件に基づいてコンポーネントを選択的にハイドレートできるようになります。これにより、必要なコンポーネントのみがロードされ、初期ロード時間とアプリケーションの全体的なパフォーマンスが向上します。
さらに、Angular の増分ハイドレーションは、ハイドレート ブロック内のコンテンツのイベント リプレイを採用して、シームレスなユーザー エクスペリエンスを保証します。 withEventReplay 機能を活用することで、フレームワークは、ハイドレーション プロセスが完了する前に発生するクリックやキーの押下などのユーザー インタラクションをキャプチャします。コンポーネントがハイドレートされると、これらの記録されたイベントが再生され、対応するイベント リスナーが実行され、移行中にユーザー インタラクションが失われることがなく、アプリケーションが最初から応答性が高く魅力的に感じられることが保証されます。
ハイドレーション トリガーについて説明する前に、Angular アプリケーションで増分ハイドレーションを使用するように設定されていることを確認してください。従う手順は次のとおりです:
プロバイダー配列の ProvideClientHydration() インポートに withIncrementalHydration() を追加することで、増分ハイドレーションをアプリケーションにインポートする必要があります。
import { provideClientHydration, withIncrementalHydration } from '@angular/platform-browser';
// Update bootstrap code
bootstrapApplication(AppComponent, {
providers: [provideClientHydration(withIncrementalHydration())]
});
増分ハイドレーション機能は、追加のハイドレートトリガーとともに deferblock で有効になります。増分ハイドレーションを利用したい遅延ブロックにハイドレート トリガーを追加する必要があります。トリガーは現在使用されているものと同じです (詳細については、このドキュメントを参照してください) に加えて、追加のハイドレート ネバー トリガーが追加されます。以下は利用可能なすべてのハイドレートトリガーのリストです:
基本的な構文は、遅延可能なビューの既存の構文と同じですが、ハイドレート固有のトリガーが追加されています。例:
@defer (hydrate on interaction) {
<my-deferred-cmp />
}
ハイドレート トリガーは、同じコード ブロック内の既存の遅延トリガーと共存します。例:
@defer (on idle; hydrate on interaction) {
<my-deferred-cmp />
}
ハイドレーション トリガーの導入は、特にサーバー側レンダリング (SSR) とクライアント側レンダリング (CSR) のコンテキストにおいて、アプリケーションによるレンダリングの管理方法に大きな進化をもたらしました。インタラクション時のハイドレートなどのハイドレート トリガーは、即時のような既存の Angular 遅延トリガーとは異なるメカニズムを提供します。
機能を明確にするために、従来の遅延トリガーはクライアント側レンダリングのコンテキストでのみ動作します。たとえば、即時トリガーは、ユーザーがクライアント側のルーティングを介してコンポーネントに移動した場合にのみアクティブ化され、初期ロードが完了すると即時レンダリングが発生する必要があることを示します。
対照的に、ハイドレート トリガーは、最初のサーバー側レンダリング中に機能します。サーバーでレンダリングされたコンポーネントがハイドレート キーワードを使用すると、コンテンツが静的 HTML として準備され、特定のハイドレーション条件が満たされるか、特定のハイドレーション トリガーが実行されるまで非対話型のままになります。これは、最初のサーバー側レンダリング中にコンポーネントが静的コンテンツとして表示されることを意味します。ただし、条件が満たされるかトリガーがアクティブになると、水分補給によって完全にインタラクティブな要素に変わります。この機能上の違いにより、通常の遅延トリガーとハイドレート トリガーは相互に排他的であると説明できます。一度に適用できるトリガーは 1 種類のみです。
この独占性により、開発者はコンポーネントがレンダリングされてインタラクティブになるタイミングを慎重に管理し、アプリケーションのパフォーマンスを最適化することができます。さらに、イベントのリプレイはハイドレート トリガーと連携して機能し、静的フェーズ中に行われたユーザー アクションが確実に保持されます。これらのインタラクションはキャプチャされ、水分補給時に再生されます。
また、ハイドレート トリガーが @placeholder および @loading とどのように相互作用するかを理解することも重要です。
ハイドレート キーワードを使用すると、メイン テンプレート コンテンツが SSR 中の新しいプレースホルダーとして効果的に機能します。対照的に、CSR シナリオでは、従来のプレースホルダーと読み込みテンプレートが利用されます。したがって、ハイドレート キーワードが使用されない場合、動作はデフォルトで標準のサーバー側レンダリングになり、指定されたプレースホルダーがサーバー上でレンダリングされ、完全なアプリケーション読み込みプロセスの一部として積極的にハイドレートされます。この微妙な違いにより、開発者は初期読み込みエクスペリエンスとその後のユーザー インタラクションの両方をシームレスに最適化できるようになります。
遅延トリガーやプリフェッチ トリガーと同様に、複数のハイドレート トリガーを同時に利用して、これらのトリガーのいずれかがアクティブ化されるたびにハイドレーションを発生させることができます。例:
import { provideClientHydration, withIncrementalHydration } from '@angular/platform-browser';
// Update bootstrap code
bootstrapApplication(AppComponent, {
providers: [provideClientHydration(withIncrementalHydration())]
});
when トリガーに関して注意すべき重要な点の 1 つは、同じ @defer ブロック内に複数のハイドレート when トリガーを含めることはできないということです。代わりに、条件を組み合わせる必要があります。それ以外の場合は、エラーがスローされます。たとえば、以下のコードでは、複数の when ブロックが許可されていないことを示すエラーが発生します:
@defer (hydrate on interaction) {
<my-deferred-cmp />
}
対照的に、以下のコードは正しく動作します:
@defer (on idle; hydrate on interaction) {
<my-deferred-cmp />
}
ハイドレーション トリガーは、遅延ブロックがいつインタラクティブになるかを決定します。各トリガーと、その使用のための理想的なシナリオを詳しく見てみましょう。
即時ハイドレーション: このトリガーは、クライアントがコンポーネントのレンダリングを終了した直後にハイドレーションを開始します。例:
@defer(hydrate on interaction; hydrate when isLoggedIn()){
<li>
<a [routerLink]="[isLoggedIn()?'/account':'/signup']">Account</a>
</li>
}
使用例: このトリガーは、ナビゲーション メニューや主要な CTA ボタンなど、すぐにユーザーと対話する必要がある重要なコンポーネントに使用します。
アイドル時にハイドレーション: このトリガーは、ブラウザーがアイドル状態 (requestIdleCallback を参照) になったときにハイドレーションを開始します。つまり、ユーザー操作やスケジュールされたタスクが存在しないことを意味します。
@defer(hydrate when firstCondition; hydrate when secondCondition){
<my-component />
}
使用例: 主な操作を妨げずにコンテキストを提供する補足情報カードなど、数分間待機できる重要ではない UI 要素に最適です。
タイマーで水分補給: このトリガーは、指定された期間の後に水分補給を有効にします。これは必須であり、ミリ秒 (ms) または秒 (s) で定義できます。
@defer(hydrate when (firstCondition || secondCondition)){
<my-component />
}
使用例: ポップアップ通知やインターフェースを通じてユーザーをガイドするチュートリアルなど、すぐにではなく短期間で表示されるコンポーネントに適しています。
Hover on Hover: このトリガーは、ユーザーが関連コンポーネントの上にマウスを移動すると、mouseenter および focusin イベントを利用して、ハイドレーションを開始します。
import { provideClientHydration, withIncrementalHydration } from '@angular/platform-browser';
// Update bootstrap code
bootstrapApplication(AppComponent, {
providers: [provideClientHydration(withIncrementalHydration())]
});
使用例: インターフェースを煩雑にすることなく、ユーザーの理解を促進するツールチップや詳細メニューなどの機能にこれを使用します。
インタラクション時にハイドレーション: このトリガーは、クリックやキーダウン イベントなどのユーザー主導のイベントに基づいてハイドレーションをアクティブ化します。
@defer (hydrate on interaction) {
<my-deferred-cmp />
}
使用例: フォーム、製品ギャラリー、クリックすると詳細情報が表示されるボタンなど、インタラクティブ性の直前にユーザーの関与が必要なコンポーネントに最適です。
ビューポートでハイドレート: このトリガーは、Intersection Observer API によって決定されたユーザーのビューポートに入ったときにコンポーネントをハイドレートします。
@defer (on idle; hydrate on interaction) {
<my-deferred-cmp />
}
使用例: ユーザーが下にスクロールするまでインタラクティブにならない、スクロールしなければ見えないコンテンツにこれを使用します。このアプローチにより、ユーザー エンゲージメントを維持しながらページの読み込み時間が短縮され、画像、記事、追加の商品リストなどのコンテンツに最適です。
決して水和しない: このトリガーは、静的なままになるブロックを指定し、決して水和してはならないことを示します。
@defer(hydrate on interaction; hydrate when isLoggedIn()){
<li>
<a [routerLink]="[isLoggedIn()?'/account':'/signup']">Account</a>
</li>
}
使用例: フッター、著作権情報、法的免責事項など、インタラクションを必要としない静的要素に最適です。これらの部分はハイドレーションのオーバーヘッドを発生させる必要がなく、単純な HTML としてレンダリングできます。
多くの場合、トリガーを組み合わせることで柔軟性とパフォーマンスが向上します。
@defer(hydrate when firstCondition; hydrate when secondCondition){
<my-component />
}
この場合、クライアント側レンダリング (CSR) では、ユーザーが下にスクロールする (ビューポートに入る) ときにコンポーネントがハイドレートするように指定します。対照的に、サーバーサイド レンダリング (SSR) の場合は、ユーザーの操作に合わせて調整され、プロセスが効率的かつユーザーのアクションに応答するようになります。
Angular 19 での増分ハイドレーションの導入により、ネストされたハイドレーションの概念は理解することが重要な側面になります。複数のネストされた @defer ブロックを処理する場合、それらのハイドレーション条件間の相互作用により、パフォーマンスとリソース管理が大幅に向上します。これらのネストされたブロックの動作を管理するルールにより、何をいつレンダリングするかをより詳細なレベルで制御でき、最終的にはアプリケーションの全体的なパフォーマンスに影響を与えます。
複数の @defer ブロックが脱水状態で相互にネストされている場合、それらの水和条件は同時に評価されます。たとえば、次の構造を考えてみましょう:
import { provideClientHydration, withIncrementalHydration } from '@angular/platform-browser';
// Update bootstrap code
bootstrapApplication(AppComponent, {
providers: [provideClientHydration(withIncrementalHydration())]
});
この例では、ユーザーがその中のコンテンツの上にマウスを移動すると、外側のブロックがハイドレートするように設定されています。ただし、外側のブロックがホバーされていない場合でも、指定された 15 秒の継続時間が経過すると、内側のブロックがハイドレーションをトリガーします。この条件の同時評価により、特にインタラクションのタイミングが大きく異なる可能性があるユーザー インターフェイスにおいて、コンポーネントがインタラクティブになる方法の柔軟性が向上します。
ほとんどのハイドレートトリガーはネストされた構造内で正しく機能しますが、トリガー時のハイドレートには注目すべき例外があります。 when トリガーは条件ベースであり、それを含むコンポーネント内で定義されたロジックに完全に依存します。具体的には、これは、直接の親ブロックまたは包含ブロックがすでにハイドレートされている場合にのみ、 when がそのロジックを評価できることを意味します。例:
@defer (hydrate on interaction) {
<my-deferred-cmp />
}
このシナリオでは、外側のブロック (ホバー時にハイドレートする) がマウスホバーイベント時にハイドレーションをトリガーしない場合、内側のブロック (ユーザーオブジェクトが null でないかどうかをチェックする) は決してハイドレートしません。この動作の理由は明らかです。親コンポーネントが処理され、そのロジックにアクセスできない限り、評価する式は実行できません。したがって、外側のブロックが脱水状態のままである場合、内側のブロックを評価するために必要なロジックがまだ存在していません。
ネストされたブロックに対してハイドレーションがトリガーされると、Angular はカスケード プロセスに従います。子コンポーネントが動作する前に、親ブロックが最初にハイドレートされる必要があります。このカスケード アクションは、ネストされたコンポーネントの依存関係を正しい順序でロードできるため、非常に重要です。水和プロセスは効果的に滝のように機能し、各ステップは完全に処理される前のステップに依存します。したがって、ネストされたデハイドレートされたブロックでは、いずれかのレベルが動作可能になる前に、すべてのレベルに必要なコードをロードするための慎重なアプローチが必要になります。
ネストされた構造で混合トリガーを利用する場合、関係するトリガーの性質を念頭に置くことが重要です。たとえば、特定のコンポーネントを水和させながら、他のコンポーネントを静的 (非水和) のままにしたい場合は、次の構造を戦略的に使用できます:
@defer (on idle; hydrate on interaction) {
<my-deferred-cmp />
}
この場合、ホバーすると外側のブロックがハイドレートしますが、広告ユニットを含む内側のブロックはハイドレートされず、静的な性質が維持されます。この分離が可能になるのは、ホバー時のハイドレートなどのイベントベースのトリガーがコンポーネントのロジックに依存せずにアクティブ化されるため、@deferblocks でネストされたロジックとは独立して動作できるためです。
Angular 19 で増分ハイドレーションを効果的に活用するには、ネストされたハイドレーションを理解することが不可欠です。ネストされた @deferblock を慎重に構造化し、適切なハイドレーション トリガーを選択することで、開発者は応答性を維持しながらアプリケーションのパフォーマンスを最適化できます。コンポーネントがいつどのようにインタラクティブになるかを管理する機能は、ネストされたハイドレーションを管理するルールと組み合わせることで、最新の Angular アプリケーションにおけるユーザー エクスペリエンスとリソース管理の大幅な向上につながる強力な機能です。
商品アイテムの遅延読み込み
電子商取引プラットフォームでは、カテゴリ ページに商品アイテムのリストを表示する場合、ユーザーが各商品を操作するかどうかは不確実です。ハイドレート構文を使用してこれらの製品を @defer ブロック内に配置すると、コンポーネントは静的コンテンツとしてレンダリングされますが、関連付けられた JavaScript は、ユーザーが特定の製品を操作するときにのみフェッチされ、ハイドレートされます。このアプローチにより、初期バンドル サイズが削減され、必要なときに製品の詳細を利用できるようにしながらパフォーマンスが最適化されます。
静的ブログ コンテンツの提供
主に静的な記事を扱うブログ プラットフォームの場合、投稿コンポーネントのハイドレート ネバー条件を利用すると、関連する JavaScript の配布を回避できます。これにより、ユーザーは対話性に伴うリソースのオーバーヘッドを発生させずに記事にアクセスできるため、読み込み時間が短縮されます。
スクロールせずに見える重いコンポーネントの最適化
ヘッダーやカルーセルなどの大きなコンポーネントがスクロールせずに見える部分に表示されるが、ヒートマップ データに基づいて最小限のユーザー インタラクションを示す場合、ハイドレーション トリガーを備えた @defer ブロックでコンポーネントをラップすると有益な場合があります。この戦略により、これらのコンポーネントは最初にレンダリングされ、そのインタラクティブな動作と関連リソースはユーザー操作時にのみ読み込まれるため、効率的なデータ転送が保証され、ユーザー エクスペリエンスが向上します。
フォームでのユーザー インタラクションの強化
ユーザーのアクションに即座に応答する必要がある入力フォームの場合、インタラクション トリガーでハイドレートを採用するのが理想的です。これにより、ユーザーがフォーム コンポーネントの操作を開始するとすぐにフォーム コンポーネントがアクティブ化されることが保証され、アプリケーションの使いやすさが向上します。
動的コンテンツまたはスクロールせずに見えるコンテンツの読み込み
動的なデータ表示や、ユーザーがスクロールするときにのみ関連するコンテンツの多いセクションの場合、ビューポート トリガーでハイドレートを利用することは有益なアプローチです。これは製品の表示だけでなく、画像や追加コンテンツにも適用され、初期読み込み時間に悪影響を与えることなくシームレスなユーザー エクスペリエンスを提供します。
アニメーション要素とのインタラクティブ性
ユーザー エンゲージメントを強化するものの、ツールチップやドロップダウンなどの主要なインタラクションには必須ではないインタラクティブな要素の場合は、ホバー トリガーでハイドレートを使用することをお勧めします。これにより、これらの要素は、ユーザーが要素の上にマウスを移動したときにのみ有効になり、初期負荷を軽量に保ちながら、必要に応じて追加のオプションを提供できるようになります。
Angular 19 の増分ハイドレーションは、アプリケーションのパフォーマンスとユーザー エクスペリエンスの両方の最適化における大幅な進歩を意味します。ハイドレーション トリガーを戦略的に利用することで、開発者はどのコンポーネントがインタラクティブになるのか、またそれがいつ行われるのかを正確に制御できます。このきめ細かいアプローチにより、効率が向上するだけでなく、シームレスなインターフェイスが保証されるため、ユーザーの満足度も向上します。
各ハイドレーション トリガーの複雑さをマスターすることで、Angular アプリケーションを向上させ、応答性、効率性を高め、ユーザー エンゲージメントを促進することができます。これらの概念を検討するときは、ユーザー ベースのニーズと、アプリケーションのさまざまな要素をいつどのようにハイドレートするかについて情報に基づいた決定を下すために、提示する特定のコンテンツを念頭に置いてください。開発を楽しんでください!
以上がAngular の増分ハイドレーションでアプリのパフォーマンスを次のレベルに引き上げますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
