L'hydratation incrémentielle dans Angular fait passer les performances de votre application au niveau supérieur

Dans le monde trépidant du développement Web, les performances et l'expérience utilisateur sont essentielles au succès de toute application. Avec Angular 19, l'équipe Angular a introduit une fonctionnalité révolutionnaire : l'hydratation incrémentielle. Cette nouvelle fonctionnalité améliore le processus d'hydratation existant et permet aux développeurs d'optimiser le chargement et l'interactivité des composants avec précision. Cet article approfondit ce qu'est l'hydratation incrémentielle, sa mise en œuvre et une analyse détaillée des déclencheurs d'hydratation à utiliser dans divers scénarios.

Comprendre l'hydratation dans Angular

L'hydratation est le processus d'activation d'une application rendue côté serveur côté client. Cela implique la réutilisation des éléments DOM rendus par le serveur, le maintien de l'état de l'application et le transfert des données déjà récupérées par le serveur. Essentiellement, l'hydratation élimine le besoin de restituer complètement le DOM, améliorant ainsi les mesures de performances telles que Core Web Vitals (CWV).

Angular 19 a introduit l'hydratation incrémentielle, qui va encore plus loin en permettant aux développeurs d'hydrater sélectivement les composants en fonction des interactions de l'utilisateur, de la visibilité ou des conditions personnalisées. Cela permet de charger uniquement les composants nécessaires, améliorant ainsi le temps de chargement initial et les performances globales de l'application.

De plus, l'hydratation incrémentielle d'Angular utilise la relecture d'événements pour le contenu des blocs d'hydrate afin de garantir une expérience utilisateur transparente. En tirant parti de la fonctionnalité withEventReplay, le framework capture les interactions des utilisateurs - telles que les clics ou les pressions sur des touches - qui ont lieu avant la fin du processus d'hydratation. Une fois les composants hydratés, ces événements enregistrés sont rejoués et les écouteurs d'événements correspondants sont exécutés, garantissant qu'aucune interaction utilisateur n'est perdue pendant la transition et que l'application se sent réactive et engageante dès le début.

Permettre une hydratation progressive

Avant de plonger dans les déclencheurs d'hydratation, assurons-nous que nous sommes configurés pour utiliser l'hydratation incrémentielle dans votre application Angular. Voici les étapes à suivre :

Conditions préalables

• Version angulaire : assurez-vous que votre application est mise à jour vers la version angulaire 19.0.0-rc.0 ou ultérieure.
• Rendu côté serveur (SSR) : SSR doit être activé dans votre application.
• Hydratation activée : activez l'hydratation dans votre configuration angulaire.
• Différer les blocs : utilisez @deferblocks pour tirer parti de l'hydratation incrémentielle.

Mise à jour du bootstrap de votre application

Vous devrez importer Incremental Hydration dans votre application en ajoutant withIncrementalHydration() à l'importation provideClientHydration() dans le tableau des fournisseurs :

import { provideClientHydration, withIncrementalHydration } from '@angular/platform-browser';

// Update bootstrap code
bootstrapApplication(AppComponent, {
providers: [provideClientHydration(withIncrementalHydration())]
});

Syntaxe d'hydratation incrémentielle

La fonctionnalité d'hydratation incrémentielle est activée sur les blocs différés ainsi que des déclencheurs d'hydratation supplémentaires. Vous devrez ajouter des déclencheurs d'hydratation aux blocs de report pour lesquels vous souhaitez utiliser une hydratation supplémentaire. Les déclencheurs sont les mêmes que ceux actuellement utilisés (reportez-vous à cette documentation pour plus d'informations), plus un hydrate supplémentaire ne se déclenche jamais. Vous trouverez ci-dessous la liste de tous les déclencheurs d'hydratation disponibles :

1. immédiat
2. au ralenti
3. sur minuterie
4. en survol
5. sur l'interaction
6. sur la fenêtre
7. jamais
8. quand

La syntaxe de base est la même que la syntaxe existante pour les vues différées, avec l'ajout de déclencheurs spécifiques à l'hydrate. Par exemple :

@defer (hydrate on interaction) {
  <my-deferred-cmp />
}

Les déclencheurs d'hydratation coexistent avec les déclencheurs de report existants dans le même bloc de code. Par exemple :

@defer (on idle; hydrate on interaction) {
  <my-deferred-cmp />
}

L'introduction des déclencheurs d'hydratation marque une évolution significative dans la façon dont les applications gèrent le rendu, notamment dans le contexte du rendu côté serveur (SSR) et du rendu côté client (CSR). Les déclencheurs d'hydratation, tels que l'hydratation lors de l'interaction, fournissent un mécanisme distinct des déclencheurs de report angulaire existants, tels que l'hydratation immédiate.

Pour clarifier leur fonctionnalité, les déclencheurs de report traditionnels fonctionnent uniquement dans le contexte du rendu côté client. Par exemple, le déclencheur immédiat n'est activé que lorsque l'utilisateur accède au composant via le routage côté client, indiquant que le rendu immédiat doit avoir lieu une fois le chargement initial terminé.

En revanche, les déclencheurs hydrate entrent en jeu lors du rendu initial côté serveur. Lorsqu'un composant rendu par le serveur utilise le mot-clé hydrate, il prépare le contenu au format HTML statique, qui reste non interactif jusqu'à ce que des conditions d'hydratation spécifiques soient remplies ou que des déclencheurs d'hydratation spécifiques soient exécutés. Cela signifie que lors du rendu initial côté serveur, le composant apparaît sous forme de contenu statique ; cependant, une fois les conditions remplies ou les déclencheurs activés, l’hydratation la transforme en un élément entièrement interactif. En raison de cette distinction fonctionnelle, nous pouvons décrire les déclencheurs de report réguliers et les déclencheurs d’hydratation comme s’excluant mutuellement ; un seul type de déclencheur peut être appliqué à la fois.

Cette exclusivité permet aux développeurs de gérer avec soin le moment où les composants sont rendus et rendus interactifs, optimisant ainsi les performances des applications. De plus, la relecture des événements fonctionne en conjonction avec les déclencheurs d'hydratation pour garantir que toutes les actions de l'utilisateur effectuées pendant la phase statique sont préservées ; ces interactions seront capturées et rejouées lors de l'hydratation.
Il est également essentiel de comprendre comment les déclencheurs d'hydratation interagissent avec @placeholder et @loading :

Lors de l'utilisation du mot-clé hydrate, le contenu principal du modèle sert effectivement de nouvel espace réservé pendant la SSR. En revanche, les espaces réservés et les modèles de chargement traditionnels sont utilisés lors des scénarios CSR. Ainsi, si le mot-clé hydrate n'est pas utilisé, le comportement par défaut est le rendu standard côté serveur, où les espaces réservés spécifiés sont rendus sur le serveur et hydratés avec impatience dans le cadre du processus complet de chargement de l'application. Cette distinction nuancée permet aux développeurs d'optimiser de manière transparente à la fois l'expérience de chargement initiale et les interactions utilisateur ultérieures.

Plusieurs déclencheurs d'hydratation

Tout comme les déclencheurs différés et les déclencheurs de prélecture, vous pouvez utiliser plusieurs déclencheurs d'hydratation simultanément, permettant à l'hydratation de se produire chaque fois que l'un de ces déclencheurs est activé. Par exemple :

import { provideClientHydration, withIncrementalHydration } from '@angular/platform-browser';

// Update bootstrap code
bootstrapApplication(AppComponent, {
providers: [provideClientHydration(withIncrementalHydration())]
});

Un point important à noter concernant le déclencheur when est que vous ne pouvez pas avoir plusieurs déclencheurs hydrate when dans le même bloc @defer. Au lieu de cela, vous devez combiner les conditions ; sinon, cela générera une erreur. Par exemple, le code ci-dessous entraînera une erreur indiquant que plusieurs blocs lorsque les blocs ne sont pas autorisés :

@defer (hydrate on interaction) {
  <my-deferred-cmp />
}

En revanche, le code ci-dessous fonctionnera correctement :

@defer (on idle; hydrate on interaction) {
  <my-deferred-cmp />
}

Les déclencheurs d’hydratation expliqués

Les déclencheurs d'hydratation déterminent le moment où un bloc différé doit devenir interactif. Explorons chaque déclencheur en détail, ainsi que les scénarios idéaux pour leur utilisation.

Hydrater immédiatement : ce déclencheur déclenche l'hydratation immédiatement après que le client a fini de rendre le composant. Par exemple :

@defer(hydrate on interaction; hydrate when isLoggedIn()){
<li>
  <a [routerLink]="[isLoggedIn()?'/account':'/signup']">Account</a>
</li>
}

Exemple de cas d'utilisation : utilisez ce déclencheur pour les composants essentiels qui nécessitent une interaction rapide de l'utilisateur immédiatement, comme les menus de navigation ou un bouton d'appel à l'action principal.

Hydrate on Idle : ce déclencheur démarre l'hydratation lorsque le navigateur entre dans un état inactif (voir requestIdleCallback), ce qui signifie qu'aucune interaction utilisateur ou tâche planifiée n'est en place.

@defer(hydrate when firstCondition; hydrate when secondCondition){
<my-component />
}

Exemple de cas d'utilisation : idéal pour les éléments d'interface utilisateur non critiques qui peuvent attendre quelques instants, tels que les cartes d'informations supplémentaires qui fournissent un contexte sans obstruer les interactions principales.

Hydrater sur minuterie : Ce déclencheur active l'hydratation après une durée spécifiée, qui est obligatoire et peut être définie en millisecondes (ms) ou en secondes (s).

@defer(hydrate when (firstCondition || secondCondition)){
<my-component />
}

Exemple de cas d'utilisation : convient aux composants qui ne doivent pas apparaître immédiatement mais plutôt après une courte durée, comme les notifications contextuelles ou les didacticiels qui guident les utilisateurs à travers l'interface.

Hydrate on Hover : ce déclencheur déclenche l'hydratation lorsque l'utilisateur survole le composant associé, en utilisant les événements mouseenter et focusin.

import { provideClientHydration, withIncrementalHydration } from '@angular/platform-browser';

// Update bootstrap code
bootstrapApplication(AppComponent, {
providers: [provideClientHydration(withIncrementalHydration())]
});

Exemple de cas d'utilisation : utilisez-le pour des fonctionnalités telles que des info-bulles ou des menus de détails qui améliorent la compréhension de l'utilisateur sans encombrer l'interface.
Hydrater lors de l'interaction : ce déclencheur active l'hydratation en fonction d'événements pilotés par l'utilisateur, tels que des événements de clic ou de frappe.

@defer (hydrate on interaction) {
  <my-deferred-cmp />
}

Exemple de cas d'utilisation : parfait pour les composants qui nécessitent l'engagement de l'utilisateur juste avant l'interactivité, tels que les formulaires, les galeries de produits ou les boutons qui révèlent plus d'informations lorsqu'ils sont cliqués.

Hydrate on Viewport : ce déclencheur hydrate le composant lorsqu'il entre dans la fenêtre d'affichage de l'utilisateur, comme déterminé par l'API Intersection Observer.

@defer (on idle; hydrate on interaction) {
  <my-deferred-cmp />
}

Exemple de cas d'utilisation : utilisez-le pour le contenu situé sous le pli qui ne doit pas devenir interactif jusqu'à ce que l'utilisateur fasse défiler vers le bas. Cette approche améliore les temps de chargement des pages tout en maintenant l'engagement des utilisateurs, ce qui la rend idéale pour le contenu tel que des images, des articles ou des listes de produits supplémentaires.

Hydrater Jamais : Ce déclencheur désigne un bloc qui restera statique, signifiant qu'il ne faudra jamais l'hydrater.

@defer(hydrate on interaction; hydrate when isLoggedIn()){
<li>
  <a [routerLink]="[isLoggedIn()?'/account':'/signup']">Account</a>
</li>
}

Exemple de cas d'utilisation : idéal pour les éléments statiques qui ne nécessitent pas d'interaction, tels que les pieds de page, les informations de droits d'auteur ou les mentions légales. Ces parties n'ont pas besoin de supporter la surcharge d'hydratation et peuvent être rendues sous forme de simple HTML.

Combiner CSR Defer et HydrationTriggers

Dans de nombreux cas, la combinaison de déclencheurs peut apporter plus de flexibilité et de performances :

@defer(hydrate when firstCondition; hydrate when secondCondition){
<my-component />
}

Dans ce cas, nous précisons que pour le rendu côté client (CSR), le composant doit s'hydrater lorsque l'utilisateur fait défiler vers le bas (entre dans la fenêtre d'affichage). En revanche, pour le rendu côté serveur (SSR), il s'hydrate lors de l'interaction de l'utilisateur, rendant le processus à la fois efficace et réactif aux actions de l'utilisateur.

Comprendre l'hydratation imbriquée dans l'hydratation incrémentielle

Avec l'introduction de l'hydratation incrémentale dans Angular 19, le concept d'hydratation imbriquée devient un aspect crucial à comprendre. Lorsqu'il s'agit de plusieurs blocs @defer imbriqués, l'interaction entre leurs conditions d'hydratation peut améliorer considérablement les performances et la gestion des ressources. Les règles régissant le comportement de ces blocs imbriqués offrent un niveau de contrôle plus approfondi sur ce qui est rendu et à quel moment, ce qui a un impact sur les performances globales de votre application.

Évaluation simultanée de l'état

Lorsque plusieurs blocs @defer sont imbriqués les uns dans les autres dans un état déshydraté, leurs conditions d'hydratation sont évaluées simultanément. Par exemple, considérons la structure suivante :

import { provideClientHydration, withIncrementalHydration } from '@angular/platform-browser';

// Update bootstrap code
bootstrapApplication(AppComponent, {
providers: [provideClientHydration(withIncrementalHydration())]
});

Dans cet exemple, le bloc externe est configuré pour s'hydrater lorsque l'utilisateur survole n'importe quel contenu qu'il contient. Cependant, même si le bloc extérieur n'est jamais survolé, le bloc intérieur déclenchera quand même l'hydratation après une durée spécifiée de 15 secondes. Cette évaluation simultanée des conditions permet une plus grande flexibilité dans la manière dont les composants deviennent interactifs, en particulier dans les interfaces utilisateur où le timing des interactions peut varier considérablement.

L'exception pour s'hydrater quand

Bien que la plupart des déclencheurs d'hydrate fonctionnent correctement dans des structures imbriquées, il existe une exception notable pour l'hydrate lors du déclenchement. Le déclencheur when est basé sur des conditions et repose entièrement sur la logique définie dans le composant qui le contient. Plus précisément, cela signifie que when ne peut évaluer sa logique que si le parent immédiat ou le bloc conteneur est déjà hydraté. Par exemple :

@defer (hydrate on interaction) {
  <my-deferred-cmp />
}

Dans ce scénario, si le bloc externe (avec hydrate en survol) ne déclenche pas l'hydratation lors d'un événement de survol de la souris, le bloc interne (qui vérifie si l'objet utilisateur n'est pas nul) ne s'hydratera jamais. La raison de ce comportement est claire : l'expression permettant d'évaluer quand ne peut s'exécuter que si le composant parent a été traité et que sa logique est accessible. Par conséquent, si le bloc externe reste déshydraté, la logique nécessaire pour évaluer le bloc interne n'existe pas encore.

Processus d'hydratation hiérarchique

Lorsque l'hydratation est déclenchée pour un bloc imbriqué, Angular suit un processus en cascade - tout bloc parent doit d'abord être hydraté avant de pouvoir agir sur le composant enfant. Cette action en cascade est essentielle car elle permet de charger les dépendances des composants imbriqués dans le bon ordre. Le processus d’hydratation fonctionne effectivement comme une cascade, où chaque étape dépend du traitement complet de la précédente. Par conséquent, les blocs déshydratés imbriqués nécessitent une approche prudente du chargement du code requis pour tous les niveaux avant que l'un d'entre eux puisse être opérationnel.

Interactions notables

Lors de l'utilisation de déclencheurs mixtes dans des structures imbriquées, il est essentiel de garder à l'esprit la nature des déclencheurs impliqués. Par exemple, si vous souhaitez que certains composants s'hydratent tout en garantissant que d'autres restent statiques (non hydratés), vous pouvez utiliser stratégiquement la structure suivante :

@defer (on idle; hydrate on interaction) {
  <my-deferred-cmp />
}

Dans ce cas, le bloc externe s'hydratera au survol, tandis que le bloc interne contenant le bloc d'annonces restera déshydraté, préservant ainsi son caractère statique. Cette séparation est possible car les déclencheurs basés sur des événements, comme l'hydrate en survol, ne dépendent pas de la logique des composants pour s'activer et peuvent donc fonctionner indépendamment de la logique contenue dans les @deferblocks imbriqués.

Comprendre l'hydratation imbriquée fait partie intégrante de l'exploitation efficace de l'hydratation incrémentielle dans Angular 19. En structurant soigneusement les @deferblocks imbriqués et en sélectionnant les déclencheurs d'hydratation appropriés, les développeurs peuvent optimiser les performances des applications tout en préservant la réactivité. La capacité de gérer quand et comment les composants deviennent interactifs est une fonctionnalité puissante qui, combinée aux règles régissant l'hydratation imbriquée, peut conduire à une expérience utilisateur et à une gestion des ressources considérablement améliorées dans les applications angulaires modernes.

Scénarios courants d'utilisation de l'hydratation incrémentielle

Chargement paresseux des articles de produits
Dans une plateforme de commerce électronique, lors de l'affichage d'une liste d'articles sur une page de catégorie, il n'est pas certain que les utilisateurs interagiront avec chaque produit. En plaçant ces produits dans un bloc @defer à l'aide de la syntaxe hydrate, les composants seront rendus sous forme de contenu statique, mais le JavaScript associé ne sera récupéré et hydraté que lorsqu'un utilisateur interagit avec un produit spécifique. Cette approche réduit la taille initiale du bundle, optimisant les performances tout en rendant les détails du produit disponibles en cas de besoin.

Servir du contenu de blog statique
Pour une plate-forme de blogs qui propose principalement des articles statiques, tirer parti de la condition hydrater jamais pour les composants de publication vous permet d'éviter d'envoyer du JavaScript associé. Cela se traduit par des temps de chargement plus légers, car les utilisateurs peuvent accéder aux articles sans encourir la surcharge de ressources généralement associée à l'interactivité.

Optimisation des composants lourds au-dessus de la ligne de flottaison
Lorsque vous avez des composants volumineux, tels qu'un en-tête ou un carrousel, qui apparaissent au-dessus de la ligne de flottaison mais affichent une interaction minimale de l'utilisateur basée sur les données de la carte thermique, les envelopper dans un bloc @defer avec un déclencheur d'hydratation peut être bénéfique. Cette stratégie permet à ces composants d'être rendus initialement, tandis que leur comportement interactif et les ressources associées ne sont chargés que lors de l'interaction de l'utilisateur, garantissant un transfert de données efficace et améliorant l'expérience utilisateur.

Améliorer l'interaction des utilisateurs avec les formulaires
Pour les formulaires de saisie qui nécessitent une réactivité immédiate aux actions de l’utilisateur, l’utilisation du déclencheur d’hydratation lors de l’interaction est idéale. Cela garantit que les composants du formulaire sont activés dès qu'un utilisateur commence à interagir avec eux, améliorant ainsi la convivialité de l'application.

Chargement de contenu dynamique ou sous la ligne de flottaison
Pour les affichages de données dynamiques ou les sections riches en contenu qui ne deviennent pertinentes que lorsque l'utilisateur fait défiler, l'utilisation du déclencheur hydrater sur la fenêtre d'affichage est une approche précieuse. Cela s'applique non seulement aux affichages de produits, mais également aux images ou au contenu supplémentaire, offrant une expérience utilisateur transparente sans affecter négativement les temps de chargement initiaux.

Interactivité avec des éléments animés
Pour les éléments interactifs qui améliorent l'engagement des utilisateurs mais qui ne sont pas essentiels pour les interactions principales, tels que les info-bulles ou les listes déroulantes, il est recommandé d'utiliser le déclencheur d'hydratation en survol. Cela garantit que ces éléments ne sont activés que lorsque les utilisateurs les survolent, ce qui permet de conserver une charge initiale légère tout en offrant des options supplémentaires en cas de besoin.

Conclusion

L'hydratation incrémentielle dans Angular 19 signifie une avancée significative dans l'optimisation des applications en termes de performances et d'expérience utilisateur. En utilisant stratégiquement les déclencheurs d’hydratation, les développeurs peuvent contrôler avec précision quels composants doivent devenir interactifs et quand cela doit se produire. Cette approche granulaire améliore non seulement l'efficacité, mais améliore également la satisfaction des utilisateurs en garantissant une interface transparente.

En maîtrisant les subtilités de chaque déclencheur d'hydratation, vous pouvez améliorer vos applications Angular, les rendant réactives, efficaces et prêtes à l'engagement des utilisateurs. Lorsque vous explorez ces concepts, gardez à l’esprit les besoins de votre base d’utilisateurs et le contenu spécifique que vous présentez pour prendre des décisions éclairées sur le moment et la manière d’hydrater divers éléments de votre application. Bon développement !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!