Présentation du cycle de vie d’un composant Blazor

Les composants Blazor ont un cycle de vie bien défini qui commence quand ils sont créés pour la première fois et se termine quand ils sont détruits. Un ensemble d’événements qui se produisent en réponse à des déclencheurs spécifiques régit le cycle de vie des composants. Ces déclencheurs sont par exemple le composant en cours d’initialisation, les interactions d’un utilisateur avec le composant ou la fermeture de la page où se trouve le composant.

Dans cette unité, vous découvrez les événements qui se produisent pendant le cycle de vie des composants Blazor. Vous verrez comment gérer ces événements pour optimiser le travail effectué et augmenter la réactivité d’une page Blazor.

Le cycle de vie des composants Blazor

Les composants Blazor représentent les vues dans les applications Blazor, qui définissent la disposition et la logique de l’interface utilisateur. Les composants génèrent un balisage HTML lors de l’exécution de l’application. Les événements d’interaction utilisateur peuvent déclencher du code personnalisé et les composants peuvent être mis à jour pour effectuer un nouveau rendu de l’affichage. Lors de la fermeture de la page, Blazor supprime le composant et nettoie les ressources. De nouvelles instances sont créées lorsque l’utilisateur retourne sur la page.

Le diagramme suivant illustre les événements qui se produisent pendant la durée de vie d’un composant, ainsi que les méthodes permettant de les gérer. Blazor fournit des versions synchrones et asynchrones de chaque méthode, à l’exception de SetParametersAsync.

Tous les composants Blazor descendent de la classe ou de l’interface ComponentBaseIComponent qui définit les méthodes affichées et fournit un comportement par défaut. Pour gérer un événement, vous devez remplacer la méthode correspondante.

Bien que le diagramme implique qu’il existe un flux à un seul thread entre les méthodes du cycle de vie, les versions asynchrones de ces méthodes permettent à une application Blazor d’accélérer le processus de rendu. Par exemple, quand le premier await se produit dans SetParametersAsync, le composant Blazor exécute les méthodes OnInitialized et OnInitializedAsync. Quand l’instruction dont l’exécution est attendue se termine, le thread d’exécution de SetParametersAsync reprend.

La même logique s’applique à toute une série de méthodes du cycle de vie. En outre, chaque await opération qui se produit pendant OnInitializedAsync et OnParametersSetAsync indique que l’état du composant a changé et peut déclencher un rendu immédiat de la page. Celle-ci est susceptible d’être affichée plusieurs fois avant l’achèvement complet de l’initialisation.

Comprendre les méthodes du cycle de vie

Chaque méthode du cycle de vie d’un composant a un objectif spécifique, et vous pouvez remplacer les méthodes pour ajouter de la logique personnalisée à votre composant. Le tableau suivant répertorie les méthodes du cycle de vie dans l’ordre où elles se produisent, et décrit leur objectif.

La méthode SetParametersAsync

Lorsqu’un utilisateur visite une page contenant un composant Blazor, le runtime Blazor crée une instance du composant et exécute le constructeur par défaut. Une fois le composant construit, le runtime Blazor appelle la méthode SetParametersAsync.

Si le composant définit des paramètres, le runtime Blazor injecte les valeurs de ces paramètres provenant de l’environnement appelant dans le composant. Ces paramètres sont contenus dans un objet ParameterView et rendus accessibles à la méthode SetParametersAsync. La méthode base.SetParametersAsync permet de remplir les propriétés de Parameter de votre composant avec ces valeurs.

Si vous devez gérer les paramètres d’une autre façon, cette méthode est l’endroit approprié pour le faire. Par exemple, vous devrez peut-être valider tous les paramètres transmis au composant avant de les utiliser.

Les méthodes OnInitialized et OnInitializedAsync

Vous pouvez remplacer les méthodes OnInitialized et OnInitializedAsync pour inclure des fonctionnalités personnalisées. Ces méthodes s’exécutent après que la méthode SetParametersAsync remplit les propriétés basées sur les paramètres du composant, qui sont attribuées avec ParameterAttribute ou CascadingParameterAttribute. Vous exécutez la logique d’initialisation dans ces méthodes.

Si la propriété render-mode de l’application est définie sur Server, les méthodes OnInitialized et OnInitializedAsync s’exécutent une seule fois pour une instance du composant. Si un parent du composant modifie les paramètres du composant, la méthode SetParametersAsync s’exécute à nouveau, mais pas ces méthodes. Si vous devez réinitialiser un composant quand les paramètres changent, utilisez la méthode SetParametersAsync. Pour procéder une seule fois à l’initialisation, servez-vous de ces méthodes.

Si la propriété render-mode est définie sur ServerPrerendered, les méthodes OnInitialized et OnInitializedAsync s’exécutent deux fois : une fois pendant la phase de prérendu qui génère la sortie de la page statique, et à nouveau quand le serveur a établi une connexion SignalR avec le navigateur. Vous pouvez effectuer des tâches d’initialisation coûteuses en temps dans ces méthodes, comme récupérer des données auprès d’un service web que vous utilisez pour définir l’état du composant Blazor. Dans ce cas, mettez en cache les informations d’état pendant la première exécution et réutilisez l’état enregistré lors de la deuxième exécution.

Toutes les dépendances utilisées par le composant Blazor sont injectées après la création de l’instance, mais avant l'exécution des méthodes OnInitialized ou OnInitializedAsync. Vous pouvez utiliser les objets injectés par ces dépendances dans les méthodes OnInitialized et OnInitializedAsync, mais pas avant.

Pendant la phase de pré-rendu, le code d’un composant Blazor Server ne peut pas effectuer des actions qui exigent une connexion au navigateur, comme appeler du code JavaScript. Vous devez placer la logique qui dépend d’une connexion avec le navigateur dans les méthodes OnAfterRender ou OnAfterRenderAsync.

Les méthodes OnParametersSet et OnParametersSetAsync

Les méthodes OnParametersSet et OnParametersSetAsync s’exécutent après les méthodes OnInitialized et OnInitializedAsync la première fois que le rendu du composant est effectué, ou après la méthode SetParametersAsync dans les rendus suivants. Comme SetParametersAsync, elles sont toujours appelées, même si le composant ne comporte pas de paramètres.

Utilisez une des méthodes pour effectuer des tâches d’initialisation qui dépendent des valeurs des paramètres du composant, par exemple déterminer la valeur de propriétés calculées. N’effectuez pas d’opérations d’une durée longue, comme celles qui sont dans un constructeur. Les constructeurs étant synchrones, le fait d’attendre la fin d’opérations d’une durée longue affecte la réactivité de la page qui contient le composant.

Méthodes OnAfterRender et OnAfterRenderAsync

Les méthodes OnAfterRender et OnAfterRenderAsync s’exécutent chaque fois que le runtime Blazor doit mettre à jour la vue représentée par le composant dans l’interface utilisateur. Cet état se produit automatiquement quand :

• L’état du composant change, par exemple quand les méthodes OnInitialized ou OnInitializedAsync ou les méthodes OnParametersSetOnParametersSetAsync s’exécutent.
• Un événement d’interface utilisateur est déclenché.
• Le code de l’application appelle la méthode StateHasChanged du composant.

Quand StateHasChanged est appelé, depuis un événement externe ou un déclencheur de l’interface utilisateur, le rendu du composant est à nouveau effectué de façon conditionnelle. La liste suivante détaille l’ordre des appels de méthode, notamment StateHasChanged :

1. StateHasChanged: marque le composant comme nécessitant un nouveau rendu.
2. ShouldRender : retourne un indicateur indiquant si le rendu du composant doit s’effectuer.
3. BuildRenderTree : effectue le rendu du composant.

La méthode StateHasChanged appelle la méthode ShouldRender du composant. L’objectif de cette méthode est de déterminer si le changement d’état exige que le composant effectue à nouveau un rendu de la vue. Par défaut, toutes les modifications d’état déclenchent une opération de rendu. Cependant, vous pouvez remplacer la méthode ShouldRender pour définir votre logique de prise de décision. La méthode ShouldRender retourne true si la vue doit être affichée à nouveau, false sinon.

Si le composant doit être rendu, vous pouvez utiliser la BuildRenderTree méthode pour générer un modèle qui peut mettre à jour la version du DOM que le navigateur utilise pour afficher l’interface utilisateur. Vous pouvez utiliser l’implémentation par défaut de la méthode qui est fournie par la classe ComponentBase, ou bien la remplacer par une logique personnalisée si vous avez des exigences spécifiques.

Ensuite, la vue du composant est affichée et l’interface utilisateur est mise à jour. Enfin, le composant exécute les méthodes OnAfterRender et OnAfterRenderAsync. À ce stade, l’interface utilisateur est entièrement fonctionnelle, et vous pouvez interagir avec JavaScript et les éléments du modèle DOM. Utilisez ces méthodes pour effectuer les autres étapes qui nécessitent un accès au contenu entièrement rendu, par exemple appeler du code JavaScript depuis l’interopérabilité JS.

Les méthodes OnAfterRender et OnAfterRenderAsync prennent un paramètre booléen appelé firstRender. Ce paramètre a la valeur true la première fois que les méthodes sont exécutées, mais false par la suite. Vous pouvez évaluer ce paramètre pour effectuer des opérations ponctuelles qui peuvent être fastidieuses et gourmandes en ressources si vous les répétez chaque fois que le composant s’affiche.

Les méthodes Dispose et DisposeAsync

Comme toute classe .NET, un composant Blazor peut utiliser des ressources managées et non managées. Le runtime récupère automatiquement les ressources managées. Vous devez cependant implémenter l’interface IDisposable ou IAsyncDisposable, et fournir une méthode Dispose ou DisposeAsync pour libérer les ressources non managées. Cette pratique réduit les risques de fuites de mémoire sur le serveur.

Gestion des exceptions dans les méthodes de cycle de vie

Si une méthode de cycle de vie d’un composant Blazor échoue, elle ferme la connexion SignalR au navigateur, ce qui entraîne l’arrêt du fonctionnement de l’application Blazor. Pour éviter ce résultat, vérifiez que vous êtes prêt à gérer les exceptions dans le cadre de la logique pour les méthodes de cycle de vie. Pour plus d’informations, consultez Gérer les erreurs dans les applications Blazor ASP.NET Core.