Gérer les erreurs dans les applications ASP.NET Core Blazor

Dans une Blazor Web App, personnalisez l’expérience dans le composant MainLayout. Étant donné que le Assistance de balise d’environnement (par exemple, <environment include="Production">...</environment>) n’est pas pris en charge dans les composants Razor , l’exemple suivant injecte IHostEnvironment pour configurer des messages d’erreur pour différents environnements.

En haut de MainLayout.razor :

@inject IHostEnvironment HostEnvironment

Créez ou modifiez le balisage de l’interface utilisateur d’erreur Blazor :

<div id="blazor-error-ui" data-nosnippet>
    @if (HostEnvironment.IsProduction())
    {
        <span>An error has occurred.</span>
    }
    else
    {
        <span>An unhandled exception occurred.</span>
    }
    <a href="" class="reload">Reload</a>
    <a class="dismiss">🗙</a>
</div>

Dans une application Blazor Server, personnalisez l’expérience dans le fichier Pages/_Host.cshtml. L’exemple suivant utilise l' Assistance de balise d’environnement pour configurer les messages d’erreur pour différents environnements.

Dans une application Blazor Server, personnalisez l’expérience dans le fichier Pages/_Layout.cshtml. L’exemple suivant utilise l' Assistance de balise d’environnement pour configurer les messages d’erreur pour différents environnements.

Dans une application Blazor Server, personnalisez l’expérience dans le fichier Pages/_Host.cshtml. L’exemple suivant utilise l' Assistance de balise d’environnement pour configurer les messages d’erreur pour différents environnements.

Créez ou modifiez le balisage de l’interface utilisateur d’erreur Blazor :

<div id="blazor-error-ui" data-nosnippet>
    <environment include="Staging,Production">
        An error has occurred.
    </environment>
    <environment include="Development">
        An unhandled exception occurred.
    </environment>
    <a href="" class="reload">Reload</a>
    <a class="dismiss">🗙</a>
</div>

L’élément blazor-error-ui est normalement masqué en raison de la présence du style display: none de la classe CSS blazor-error-ui dans la feuille de style générée automatiquement de l’application. Lorsqu’une erreur se produit, le framework applique display: block à l’élément.

L’élément blazor-error-ui est normalement masqué en raison de la présence du style display: none de la classe CSS blazor-error-ui dans la feuille de style du site dans le dossier wwwroot/css. Lorsqu’une erreur se produit, le framework applique display: block à l’élément.

Cette section s’applique aux Blazor Web App fonctionnant sur un circuit.

Cette section s’applique aux applications Blazor Server.

Erreurs détaillées pour le rendu côté serveur du composant Razor

Cette section s’applique aux Blazor Web App.

Utilisez l’option RazorComponentsServiceOptions.DetailedErrors pour contrôler la production d’informations détaillées sur les erreurs pour le rendu côté serveur du composant Razor. La valeur par défaut est false.

L’exemple suivant active les erreurs détaillées :

builder.Services.AddRazorComponents(options => 
    options.DetailedErrors = builder.Environment.IsDevelopment());

Pour connaître les approches de gestion globale des exceptions, consultez les sections suivantes :

• Limites d’erreur : s’applique à toutes les applications Blazor.
• Autre gestion globale des exceptions : s’applique aux Blazor Server, Blazor WebAssembly et Blazor Web App (8.0 ou versions ultérieures) qui adoptent un mode de rendu interactif global.

Limites d’erreur

Les limites d’erreur fournissent une approche pratique pour la gestion des exceptions. Le composant ErrorBoundary :

• Affiche son contenu enfant lorsqu’une erreur ne s’est pas produite.
• Affiche l’interface utilisateur d’erreur lorsqu’une exception non prise en charge est levée par n’importe quel composant dans la limite d’erreur.

Pour définir une limite d’erreur, utilisez le composant ErrorBoundary pour encapsuler un ou plusieurs autres composants. La limite d’erreur gère les exceptions non gérées levées par les composants qu’elle encapsule.

<ErrorBoundary>
    ...
</ErrorBoundary>

Pour implémenter une limite d’erreur de manière globale, ajoutez la limite autour du contenu du corps du layout principal de l’application.

Dans MainLayout.razor:

<article class="content px-4">
    <ErrorBoundary>
        @Body
    </ErrorBoundary>
</article>

Dans les Blazor Web App avec la limite d’erreur appliquée uniquement à un composant MainLayout statique, la limite est active uniquement pendant la phase de rendu statique côté serveur (SSR statique). La limite ne s’active pas juste parce qu’un composant plus bas dans la hiérarchie des composants est interactif.

Un mode de rendu interactif ne peut pas être appliqué au composant MainLayout, car le paramètre Body du composant est un délégué RenderFragment, qui est un code arbitraire et ne peut pas être sérialisé. Pour permettre une interactivité à grande échelle pour le composant MainLayout et le rest des composants situés plus bas dans la hiérarchie des composants, l’application doit adopter un mode de rendu interactif global en appliquant le mode de rendu interactif aux instances de HeadOutlet et Routes dans le composant racine de l’application, qui est généralement le composant App. L’exemple suivant adopte globalement le mode de rendu de serveur interactif (InteractiveServer).

Dans Components/App.razor :

<HeadOutlet @rendermode="InteractiveServer" />

...

<Routes @rendermode="InteractiveServer" />

Si vous préférez ne pas activer l’interactivité globale, placez la limite d’erreur plus loin dans la hiérarchie des composants. Les concepts importants à garder à l’esprit sont que chaque fois que la limite d’erreur est placée :

• Si le composant où se trouve la limite d’erreur n’est pas interactif, la limite d’erreur peut uniquement s’activer sur le serveur pendant le SSR statique. Par exemple, la limite peut s’activer lorsqu’une erreur est levée dans une méthode de cycle de vie de composant, mais pas pour un événement déclenché par l’interactivité utilisateur au sein du composant, par exemple une erreur levée par un gestionnaire de clics de bouton.
• Si le composant où se trouve la limite d’erreur est interactif, la limite d’erreur peut s’activer pour les composants interactifs qu’elle encapsule.

Prenons l’exemple suivant, où une exception levée par un composant de compteur incorporé est interceptée par une limite d’erreur dans le composant Home, qui adopte un mode de rendu interactif.

EmbeddedCounter.razor :

<h1>Embedded Counter</h1>

<p role="status">Current count: @currentCount</p>
<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;

        if (currentCount > 5)
        {
            throw new InvalidOperationException("Current count is too big!");
        }
    }
}

Home.razor :

@page "/"
@rendermode InteractiveServer

<PageTitle>Home</PageTitle>

<h1>Home</h1>

<ErrorBoundary>
    <EmbeddedCounter />
</ErrorBoundary>

Prenons l’exemple suivant, où une exception levée par un composant de compteur incorporé est interceptée par une limite d’erreur dans le composant Home.

EmbeddedCounter.razor :

<h1>Embedded Counter</h1>

<p role="status">Current count: @currentCount</p>
<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;

        if (currentCount > 5)
        {
            throw new InvalidOperationException("Current count is too big!");
        }
    }
}

Home.razor :

@page "/"

<PageTitle>Home</PageTitle>

<h1>Home</h1>

<ErrorBoundary>
    <EmbeddedCounter />
</ErrorBoundary>

Si l’exception non prises en charge est levée pour un currentCount de plus de cinq :

• L’erreur est enregistrée normalement (System.InvalidOperationException: Current count is too big!).
• L’exception est gérée par la limite d’erreur.
• L’interface utilisateur d’erreur par défaut est rendue par la limite d’erreur.

Le composant ErrorBoundary affiche un élément <div> vide avec la classe CSS blazor-error-boundary pour son contenu d’erreur. Les couleurs, le texte et l’icône de l’interface utilisateur par défaut sont définis dans la feuille de style de l’application dans le dossier wwwroot. Vous êtes donc libre de personnaliser l’interface utilisateur d’erreur.

Pour modifier le contenu d’erreur par défaut :

• Encapsulez les composants de la limite d’erreur dans la propriété ChildContent.
• Définissez la propriété ErrorContent sur le contenu d’erreur.

L’exemple suivant encapsule le composant EmbeddedCounter et fournit le contenu d’erreur personnalisé :

<ErrorBoundary>
    <ChildContent>
        <EmbeddedCounter />
    </ChildContent>
    <ErrorContent>
        <p class="errorUI">😈 A rotten gremlin got us. Sorry!</p>
    </ErrorContent>
</ErrorBoundary>

Pour l’exemple précédent, la feuille de style de l’application inclut vraisemblablement une classe CSS errorUI pour mettre en forme le contenu. Le contenu d’erreur est rendu à partir de la propriété ErrorContent sans élément de niveau bloc. Un élément de niveau bloc, tel qu’un élément de division (<div>) ou de paragraphe (<p>), peut encapsuler le balisage de contenu d’erreur, mais il n’est pas nécessaire.

Si vous le souhaitez, utilisez le contexte (@context) de l’objet ErrorContent pour obtenir les données d’erreur :

<ErrorContent>
    @context.HelpLink
</ErrorContent>

L’objet ErrorContent peut également nommer le contexte. Dans l’exemple suivant, le contexte est nommé exception :

<ErrorContent Context="exception">
    @exception.HelpLink
</ErrorContent>

Si la limite d’erreur est définie dans la disposition de l’application, l’interface utilisateur d’erreur est visible, quelle que soit la page vers laquelle l’utilisateur accède après l’erreur. Dans la plupart des scénarios, nous vous recommandons de définir étroitement les limites d’erreur. Si vous limitez largement une limite d’erreur, vous pouvez la réinitialiser à un état non d’erreur sur les événements de navigation de page suivants en appelant la méthode Recover de la limite d’erreur.

Dans MainLayout.razor:

• Ajoutez un champ pour le ErrorBoundary à capturer une référence à celle-ci avec la directive d’attribut @ref.
• Dans la méthode de cycle de vie OnParameterSet, vous pouvez déclencher une récupération au niveau de la limite de l’erreur avec Recover afin d’effacer l’erreur lorsque l’utilisateur accède à un autre composant.

...

<ErrorBoundary @ref="errorBoundary">
    @Body
</ErrorBoundary>

...

@code {
    private ErrorBoundary? errorBoundary;

    protected override void OnParametersSet()
    {
        errorBoundary?.Recover();
    }
}

Pour éviter la boucle infinie où la récupération revient simplement à réactiver un composant qui lève à nouveau l’erreur, n’appelez pas Recover de la logique de rendu. Appelez uniquement Recover lorsque :

• L’utilisateur effectue un mouvement d’interface utilisateur, par exemple en sélectionnant un bouton pour indiquer qu’il souhaite réessayer une procédure ou lorsque l’utilisateur accède à un nouveau composant.
• Une logique supplémentaire qui s’exécute efface également l’exception. Lorsque le composant est remangé, l’erreur ne se reproduit pas.

L’exemple suivant permet à l’utilisateur de se libérer de l’exception à l’aide d’un bouton :

<ErrorBoundary @ref="errorBoundary">
    <ChildContent>
        <EmbeddedCounter />
    </ChildContent>
    <ErrorContent>
        <div class="alert alert-danger" role="alert">
            <p class="fs-3 fw-bold">😈 A rotten gremlin got us. Sorry!</p>
            <p>@context.HelpLink</p>
            <button class="btn btn-info" @onclick="_ => errorBoundary?.Recover()">
                Clear
            </button>
        </div>
    </ErrorContent>
</ErrorBoundary>

@code {
    private ErrorBoundary? errorBoundary;
}

Vous pouvez également utiliser une sous-classe pour ErrorBoundary pour un traitement personnalisé en remplaçant OnErrorAsync. L’exemple suivant consigne simplement l’erreur, mais vous pouvez implémenter le code de gestion des erreurs de votre choix. Vous pouvez supprimer la ligne qui renvoie une CompletedTask si votre code attend une tâche asynchrone.

CustomErrorBoundary.razor :

@inherits ErrorBoundary
@inject ILogger<CustomErrorBoundary> Logger

@if (CurrentException is null)
{
    @ChildContent
}
else if (ErrorContent is not null)
{
    @ErrorContent(CurrentException)
}

@code {
    protected override Task OnErrorAsync(Exception ex)
    {
        Logger.LogError(ex, "😈 A rotten gremlin got us. Sorry!");
        return Task.CompletedTask;
    }
}

L’exemple précédent peut également être implémenté en tant que classe.

CustomErrorBoundary.cs :

using Microsoft.AspNetCore.Components;
using Microsoft.AspNetCore.Components.Web;

namespace BlazorSample;

public class CustomErrorBoundary : ErrorBoundary
{
    [Inject]
    ILogger<CustomErrorBoundary> Logger {  get; set; } = default!;

    protected override Task OnErrorAsync(Exception ex)
    {
        Logger.LogError(ex, "😈 A rotten gremlin got us. Sorry!");
        return Task.CompletedTask;
    }
}

L’une des implémentations précédentes utilisées dans un composant :

<CustomErrorBoundary>
    ...
</CustomErrorBoundary>

Gestion globale des exceptions alternative

L’approche décrite dans cette section s’applique aux Blazor Server, Blazor WebAssembly et Blazor Web App qui adoptent un mode de rendu interactif global (InteractiveServer, InteractiveWebAssembly ou InteractiveAuto). L’approche ne fonctionne pas avec les Blazor Web App qui adoptent des modes de rendu par page ou par composant, ou un rendu statique côté serveur (SSR statique), car l’approche s’appuie sur un CascadingValue/CascadingParameter, qui ne fonctionne pas sur les limites du mode de rendu ou avec les composants qui adoptent le SSR statique.

Une alternative à l’utilisation des limites d’erreur (ErrorBoundary) consiste à passer un composant d’erreur personnalisé en tant que CascadingValue aux composants enfants. L’un des avantages de l’utilisation d’un composant par rapport à l’utilisation d’un service injecté ou d’une implémentation d’enregistreur d’événements personnalisé est qu’un composant en cascade peut restituer du contenu et appliquer des styles CSS en cas d’erreur.

L’exemple de composant ProcessError suivant journalise simplement les erreurs, mais les méthodes du composant peuvent traiter les erreurs de n’importe quelle façon requise par l’application, notamment en utilisant plusieurs méthodes de traitement des erreurs.

ProcessError.razor :

@inject ILogger<ProcessError> Logger

<CascadingValue Value="this">
    @ChildContent
</CascadingValue>

@code {
    [Parameter]
    public RenderFragment? ChildContent { get; set; }

    public void LogError(Exception ex)
    {
        Logger.LogError("ProcessError.LogError: {Type} Message: {Message}", 
            ex.GetType(), ex.Message);

        // Call StateHasChanged if LogError directly participates in 
        // rendering. If LogError only logs or records the error,
        // there's no need to call StateHasChanged.
        //StateHasChanged();
    }
}

Lorsque vous utilisez cette approche dans une Blazor Web App, ouvrez le composant Routes et encapsulez le composant Router (<Router>...</Router>) avec le composant ProcessError. Cela permet au composant ProcessError de descendre en cascade vers n’importe quel composant de l’application où le composant ProcessError est reçu en tant que CascadingParameter.

Dans Routes.razor :

<ProcessError>
    <Router ...>
        ...
    </Router>
</ProcessError>

Lorsque vous utilisez cette approche dans une application Blazor Server ou Blazor WebAssembly, ouvrez le composant App, encapsulez le composant Router (<Router>...</Router>) avec le composant ProcessError. Cela permet au composant ProcessError de descendre en cascade vers n’importe quel composant de l’application où le composant ProcessError est reçu en tant que CascadingParameter.

Dans App.razor:

<ProcessError>
    <Router ...>
        ...
    </Router>
</ProcessError>

Pour traiter les erreurs dans un composant :

• Désignez le composant ProcessError en tant que CascadingParameter dans le bloc @code. Dans un exemple de composant Counter dans une application basée sur un modèle de projet Blazor, ajoutez la propriété ProcessError suivante :

  [CascadingParameter]
  public ProcessError? ProcessError { get; set; }
  

• Appelez une méthode de traitement des erreurs dans n’importe quel bloc catch avec un type d’exception approprié. L’exemple de composant ProcessError n’offre qu’une seule méthode LogError, mais le composant de traitement des erreurs peut fournir un nombre quelconque de méthodes de traitement des erreurs pour répondre à d’autres exigences de traitement des erreurs dans l’application. L’exemple de block @code du composant Counter suivant inclut le paramètre en cascade ProcessError et intercepte une exception pour la journalisation lorsque le nombre est supérieur à cinq :

  @code {
      private int currentCount = 0;
  
      [CascadingParameter]
      public ProcessError? ProcessError { get; set; }
  
      private void IncrementCount()
      {
          try
          {
              currentCount++;
  
              if (currentCount > 5)
              {
                  throw new InvalidOperationException("Current count is over five!");
              }
          }
          catch (Exception ex)
          {
              ProcessError?.LogError(ex);
          }
      }
  }
  

Erreur journalisée :

fail: {COMPONENT NAMESPACE}.ProcessError[0]
ProcessError.LogError: System.InvalidOperationException Message: Current count is over five!

Si la méthode LogError participe directement au rendu, comme l’affichage d’une barre de messages d’erreur personnalisée ou la modification des styles CSS des éléments rendus, appelez StateHasChanged à la fin de la méthode LogError pour réactiver l’interface utilisateur.

Étant donné que les approches de cette section gèrent les erreurs avec une instruction try-catch, la connexion d’une application SignalR entre le client et le serveur n’est pas interrompue lorsqu’une erreur se produit, et le circuit reste actif. Les autres exceptions non prises en charge restent irrécupérables pour un circuit. Pour plus d’informations, consultez la section sur comment un circuit réagit aux exceptions non gérées.

Une application peut utiliser un composant de traitement des erreurs comme valeur en cascade pour traiter les erreurs de manière centralisée.

Le composant ProcessError suivant se transmet lui-même en tant que CascadingValue aux composants enfants. L’exemple journalise simplement l’erreur, mais les méthodes du composant peuvent traiter les erreurs de n’importe quelle façon requise par l’application, notamment en utilisant plusieurs méthodes de traitement des erreurs. L’un des avantages de l’utilisation d’un composant par rapport à l’utilisation d’un service injecté ou d’une implémentation d’enregistreur d’événements personnalisé est qu’un composant en cascade peut restituer du contenu et appliquer des styles CSS en cas d’erreur.

ProcessError.razor :

@using Microsoft.Extensions.Logging
@inject ILogger<ProcessError> Logger

<CascadingValue Value="this">
    @ChildContent
</CascadingValue>

@code {
    [Parameter]
    public RenderFragment ChildContent { get; set; }

    public void LogError(Exception ex)
    {
        Logger.LogError("ProcessError.LogError: {Type} Message: {Message}", 
            ex.GetType(), ex.Message);
    }
}

Dans le composant App, encapsulez le composant Router avec le composant ProcessError. Cela permet au composant ProcessError de descendre en cascade vers n’importe quel composant de l’application où le composant ProcessError est reçu en tant que CascadingParameter.

App.razor :

<ProcessError>
    <Router ...>
        ...
    </Router>
</ProcessError>

Pour traiter les erreurs dans un composant :

• Désignez le composant ProcessError en tant que CascadingParameter dans le bloc @code :

  [CascadingParameter]
  public ProcessError ProcessError { get; set; }
  

• Appelez une méthode de traitement des erreurs dans n’importe quel bloc catch avec un type d’exception approprié. L’exemple de composant ProcessError n’offre qu’une seule méthode LogError, mais le composant de traitement des erreurs peut fournir un nombre quelconque de méthodes de traitement des erreurs pour répondre à d’autres exigences de traitement des erreurs dans l’application.

  try
  {
      ...
  }
  catch (Exception ex)
  {
      ProcessError.LogError(ex);
  }
  

À l’aide de l’exemple précédent de composant ProcessError et de la LogError méthode, la console des outils de développement du navigateur indique l’erreur interceptée et journalisée :

fail: {COMPONENT NAMESPACE}.Shared.ProcessError[0]
ProcessError.LogError: System.NullReferenceException Message: Object reference not set to an instance of an object.

Si la méthode LogError participe directement au rendu, comme l’affichage d’une barre de messages d’erreur personnalisée ou la modification des styles CSS des éléments rendus, appelez StateHasChanged à la fin de la méthode LogError pour réactiver l’interface utilisateur.

Étant donné que les approches de cette section gèrent les erreurs avec une instruction try-catch, la connexion SignalR d’une application Blazor entre le client et le serveur n’est pas interrompue lorsqu’une erreur se produit, et le circuit reste actif. Toute exception non prise en charge est irrécupérable pour un circuit. Pour plus d’informations, consultez la section sur comment un circuit réagit aux exceptions non gérées.

Si une exception non gérée se produit, l’exception est enregistrée dans les instances ILogger configurées dans le conteneur de service. Les applications Blazor consignent dans la sortie de la console à l’aide du fournisseur de journalisation de la console. Envisagez de vous connecter à un emplacement sur le serveur (ou l’API web principale pour les applications côté client) avec un fournisseur qui gère la taille des journaux et la rotation des journaux. L’application peut également utiliser un service de gestion des performances des applications (APM), comme Azure Application Insights (Azure Monitor).

Pendant le développement dans une application Blazor fonctionnant sur un circuit, l’application envoie généralement les détails complets des exceptions à la console du navigateur pour faciliter le débogage. En production, les erreurs détaillées ne sont pas envoyées aux clients, mais les détails complets d’une exception sont enregistrés sur le serveur.

Vous devez déterminer quels incidents journaliser et le niveau de gravité des incidents journalisés. Des utilisateurs hostiles pourraient être en mesure de déclencher des erreurs délibérément. Par exemple, ne journalisez pas d’incident à partir d’une erreur où un ProductId inconnu est fourni dans l’URL d’un composant qui affiche les détails du produit. Toutes les erreurs ne doivent pas être traitées comme des incidents pour la journalisation.

Pour plus d’informations, consultez les articles suivants :

• Journalisation ASP.NET Core Blazor
• Gérer les erreurs dans ASP.NET Core‡
• Créer des API web avec ASP.NET Core

‡S’applique aux applications Blazor côté serveur et à d’autres applications ASP.NET Core côté serveur qui sont des applications back-end d’API web pour Blazor. Les applications côté client peuvent intercepter et envoyer des informations d’erreur sur le client à une API web, qui enregistre les informations d’erreur sur un fournisseur de journalisation persistant.

Si une exception non gérée se produit, l’exception est enregistrée dans les instances ILogger configurées dans le conteneur de service. Les applications Blazor consignent dans la sortie de la console à l’aide du fournisseur de journalisation de la console. Envisagez de journaliser vers un emplacement plus permanent sur le serveur en envoyant des informations d’erreur à une API web back-end qui utilise un fournisseur de journalisation avec la gestion de la taille des journaux et la rotation des journaux. L’application d’API web back-end peut également utiliser un service de gestion des performances des applications (APM), comme Azure Application Insights (Azure Monitor)†, pour enregistrer les informations d’erreur qu’elle reçoit des clients.

Vous devez déterminer quels incidents journaliser et le niveau de gravité des incidents journalisés. Des utilisateurs hostiles pourraient être en mesure de déclencher des erreurs délibérément. Par exemple, ne journalisez pas d’incident à partir d’une erreur où un ProductId inconnu est fourni dans l’URL d’un composant qui affiche les détails du produit. Toutes les erreurs ne doivent pas être traitées comme des incidents pour la journalisation.

Pour plus d’informations, consultez les articles suivants :

• Journalisation ASP.NET Core Blazor
• Gérer les erreurs dans ASP.NET Core‡
• Créer des API web avec ASP.NET Core

†Les fonctionnalités de Application Insights natives pour prendre en charge les applications côté client et la prise en charge native de Blazor framework pour Google Analytics peuvent devenir disponibles dans les futures versions de ces technologies. Pour plus d’informations, consultez Prise en charge d’App Insights dans Blazor WASM côté client (microsoft/ApplicationInsights-dotnet #2143) et Analyse web et diagnostics (comprend des liens vers des implémentations de la communauté) (dotnet/aspnetcore #5461). En attendant, une application côté client peut utiliser le SDK JavaScript Application Insights avec JSinteropérabilité pour consigner des erreurs directement dans Application Insights à partir d’une application côté client.

‡S’applique aux applications ASP.NET Core côté serveur qui sont des applications back-end d’API web pour les applications Blazor. Les applications côté client interceptent et envoient des informations d’erreur à une API web, qui consigne les informations d’erreur à un fournisseur de journalisation persistant.

• Instanciation de composant
• Méthodes de cycle de vie
• Logique de rendu
• Gestionnaires d’événements
• Mise au rebut des supports
• Interopérabilité JavaScript
• Prérendu

• Instanciation de composant
• Méthodes de cycle de vie
• Logique de rendu
• Gestionnaires d’événements
• Mise au rebut des supports
• Interopérabilité JavaScript
• Prérendu

@page "/product-details/{ProductId:int?}"
@inject ILogger<ProductDetails> Logger
@inject IProductRepository Product

<PageTitle>Product Details</PageTitle>

<h1>Product Details Example</h1>

@if (details != null)
{
    <h2>@details.ProductName</h2>
    <p>
        @details.Description
        <a href="@details.Url">Company Link</a>
    </p>
    
}
else if (loadFailed)
{
    <h1>Sorry, we could not load this product due to an error.</h1>
}
else
{
    <h1>Loading...</h1>
}

@code {
    private ProductDetail? details;
    private bool loadFailed;

    [Parameter]
    public int ProductId { get; set; }

    protected override async Task OnParametersSetAsync()
    {
        try
        {
            loadFailed = false;

            // Reset details to null to display the loading indicator
            details = null;

            details = await Product.GetProductByIdAsync(ProductId);
        }
        catch (Exception ex)
        {
            loadFailed = true;
            Logger.LogWarning(ex, "Failed to load product {ProductId}", ProductId);
        }
    }

    public class ProductDetail
    {
        public string? ProductName { get; set; }
        public string? Description { get; set; }
        public string? Url { get; set; }
    }

    /*
    * Register the service in Program.cs:
    * using static BlazorSample.Components.Pages.ProductDetails;
    * builder.Services.AddScoped<IProductRepository, ProductRepository>();
    */

    public interface IProductRepository
    {
        public Task<ProductDetail> GetProductByIdAsync(int id);
    }

    public class ProductRepository : IProductRepository
    {
        public Task<ProductDetail> GetProductByIdAsync(int id)
        {
            return Task.FromResult(
                new ProductDetail()
                {
                    ProductName = "Flowbee ",
                    Description = "The Revolutionary Haircutting System You've Come to Love!",
                    Url = "https://flowbee.com/"
                });
        }
    }
}

@page "/product-details/{ProductId:int?}"
@inject ILogger<ProductDetails> Logger
@inject IProductRepository Product

<PageTitle>Product Details</PageTitle>

<h1>Product Details Example</h1>

@if (details != null)
{
    <h2>@details.ProductName</h2>
    <p>
        @details.Description
        <a href="@details.Url">Company Link</a>
    </p>
    
}
else if (loadFailed)
{
    <h1>Sorry, we could not load this product due to an error.</h1>
}
else
{
    <h1>Loading...</h1>
}

@code {
    private ProductDetail? details;
    private bool loadFailed;

    [Parameter]
    public int ProductId { get; set; }

    protected override async Task OnParametersSetAsync()
    {
        try
        {
            loadFailed = false;

            // Reset details to null to display the loading indicator
            details = null;

            details = await Product.GetProductByIdAsync(ProductId);
        }
        catch (Exception ex)
        {
            loadFailed = true;
            Logger.LogWarning(ex, "Failed to load product {ProductId}", ProductId);
        }
    }

    public class ProductDetail
    {
        public string? ProductName { get; set; }
        public string? Description { get; set; }
        public string? Url { get; set; }
    }

    /*
    * Register the service in Program.cs:
    * using static BlazorSample.Components.Pages.ProductDetails;
    * builder.Services.AddScoped<IProductRepository, ProductRepository>();
    */

    public interface IProductRepository
    {
        public Task<ProductDetail> GetProductByIdAsync(int id);
    }

    public class ProductRepository : IProductRepository
    {
        public Task<ProductDetail> GetProductByIdAsync(int id)
        {
            return Task.FromResult(
                new ProductDetail()
                {
                    ProductName = "Flowbee ",
                    Description = "The Revolutionary Haircutting System You've Come to Love!",
                    Url = "https://flowbee.com/"
                });
        }
    }
}

@page "/product-details/{ProductId:int}"
@using Microsoft.Extensions.Logging
@inject ILogger<ProductDetails> Logger
@inject IProductRepository ProductRepository

@if (details != null)
{
    <h1>@details.ProductName</h1>
    <p>@details.Description</p>
}
else if (loadFailed)
{
    <h1>Sorry, we could not load this product due to an error.</h1>
}
else
{
    <h1>Loading...</h1>
}

@code {
    private ProductDetail? details;
    private bool loadFailed;

    [Parameter]
    public int ProductId { get; set; }

    protected override async Task OnParametersSetAsync()
    {
        try
        {
            loadFailed = false;

            // Reset details to null to display the loading indicator
            details = null;

            details = await ProductRepository.GetProductByIdAsync(ProductId);
        }
        catch (Exception ex)
        {
            loadFailed = true;
            Logger.LogWarning(ex, "Failed to load product {ProductId}", ProductId);
        }
    }

    public class ProductDetail
    {
        public string? ProductName { get; set; }
        public string? Description { get; set; }
    }

    public interface IProductRepository
    {
        public Task<ProductDetail> GetProductByIdAsync(int id);
    }
}

@page "/product-details/{ProductId:int}"
@using Microsoft.Extensions.Logging
@inject ILogger<ProductDetails> Logger
@inject IProductRepository ProductRepository

@if (details != null)
{
    <h1>@details.ProductName</h1>
    <p>@details.Description</p>
}
else if (loadFailed)
{
    <h1>Sorry, we could not load this product due to an error.</h1>
}
else
{
    <h1>Loading...</h1>
}

@code {
    private ProductDetail? details;
    private bool loadFailed;

    [Parameter]
    public int ProductId { get; set; }

    protected override async Task OnParametersSetAsync()
    {
        try
        {
            loadFailed = false;

            // Reset details to null to display the loading indicator
            details = null;

            details = await ProductRepository.GetProductByIdAsync(ProductId);
        }
        catch (Exception ex)
        {
            loadFailed = true;
            Logger.LogWarning(ex, "Failed to load product {ProductId}", ProductId);
        }
    }

    public class ProductDetail
    {
        public string? ProductName { get; set; }
        public string? Description { get; set; }
    }

    public interface IProductRepository
    {
        public Task<ProductDetail> GetProductByIdAsync(int id);
    }
}

@page "/product-details/{ProductId:int}"
@using Microsoft.Extensions.Logging
@inject ILogger<ProductDetails> Logger
@inject IProductRepository ProductRepository

@if (details != null)
{
    <h1>@details.ProductName</h1>
    <p>@details.Description</p>
}
else if (loadFailed)
{
    <h1>Sorry, we could not load this product due to an error.</h1>
}
else
{
    <h1>Loading...</h1>
}

@code {
    private ProductDetail details;
    private bool loadFailed;

    [Parameter]
    public int ProductId { get; set; }

    protected override async Task OnParametersSetAsync()
    {
        try
        {
            loadFailed = false;

            // Reset details to null to display the loading indicator
            details = null;

            details = await ProductRepository.GetProductByIdAsync(ProductId);
        }
        catch (Exception ex)
        {
            loadFailed = true;
            Logger.LogWarning(ex, "Failed to load product {ProductId}", ProductId);
        }
    }

    public class ProductDetail
    {
        public string ProductName { get; set; }
        public string Description { get; set; }
    }

    public interface IProductRepository
    {
        public Task<ProductDetail> GetProductByIdAsync(int id);
    }
}

@page "/product-details/{ProductId:int}"
@using Microsoft.Extensions.Logging
@inject ILogger<ProductDetails> Logger
@inject IProductRepository ProductRepository

@if (details != null)
{
    <h1>@details.ProductName</h1>
    <p>@details.Description</p>
}
else if (loadFailed)
{
    <h1>Sorry, we could not load this product due to an error.</h1>
}
else
{
    <h1>Loading...</h1>
}

@code {
    private ProductDetail details;
    private bool loadFailed;

    [Parameter]
    public int ProductId { get; set; }

    protected override async Task OnParametersSetAsync()
    {
        try
        {
            loadFailed = false;

            // Reset details to null to display the loading indicator
            details = null;

            details = await ProductRepository.GetProductByIdAsync(ProductId);
        }
        catch (Exception ex)
        {
            loadFailed = true;
            Logger.LogWarning(ex, "Failed to load product {ProductId}", ProductId);
        }
    }

    public class ProductDetail
    {
        public string ProductName { get; set; }
        public string Description { get; set; }
    }

    public interface IProductRepository
    {
        public Task<ProductDetail> GetProductByIdAsync(int id);
    }
}

Prérendu

Razor composants sont pré-affichés par défaut afin que leur balisage HTML rendu soit retourné dans le cadre de la requête HTTP initiale de l’utilisateur.

Dans une application Blazor fonctionnant sur un circuit, le pré-affichage fonctionne par :

• Création d’un nouveau circuit pour tous les composants prérendus qui font partie de la même page.
• Génération du HTML initial.
• Traitement du circuit comme disconnected jusqu’à ce que le navigateur de l’utilisateur établisse une connexion SignalR au même serveur. Une fois la connexion établie, l’interactivité sur le circuit reprend et le balisage HTML des composants est mis à jour.

Pour les composants côté client pré-affichés, le pré-affichage fonctionne par :

• Générant le code HTML initial sur le serveur pour tous les composants prérendus qui font partie de la même page.
• Rendant le composant interactif sur le client une fois que le navigateur a chargé le code compilé de l’application et le runtime .NET (s’il n’est pas déjà chargé) en arrière-plan.

Si un composant lève une exception non prise en charge pendant le prérendu, par exemple, au cours d’une méthode de cycle de vie ou dans une logique de rendu :

• Dans une application Blazor fonctionnant sur un circuit, l’exception est irrécupérable pour le circuit. Pour les composants côté client prédéfinis, l’exception empêche le rendu du composant.
• L’exception est levée dans la pile des appels à partir du ComponentTagHelper.

Dans des circonstances normales où le prérendu échoue, la poursuite de la génération et du rendu du composant n’a pas de sens, car un composant de travail ne peut pas être rendu.

Pour tolérer les erreurs qui peuvent se produire pendant le prérendu, la logique de gestion des erreurs doit être placée à l’intérieur d’un composant qui peut lever des exceptions. Utilisez des instructions try-catch avec la gestion et la journalisation des erreurs. Au lieu d’encapsuler le ComponentTagHelper dans une instruction try-catch, placez la logique de gestion des erreurs dans le composant rendu par le ComponentTagHelper.

• Gérer les exceptions interceptées en dehors du cycle de vie d’un composant Razor
• Journalisation ASP.NET Core Blazor
• Gérer les erreurs dans ASP.NET Core†
• Créer des API web avec ASP.NET Core
• Blazor exemples de référentiel GitHub (dotnet/blazor-samples) (comment télécharger)

• Journalisation ASP.NET Core Blazor
• Gérer les erreurs dans ASP.NET Core†
• Créer des API web avec ASP.NET Core
• Blazor exemples de référentiel GitHub (dotnet/blazor-samples) (comment télécharger)