Gestire gli errori nelle app core Blazor ASP.NET

In un Blazor Web Appoggetto personalizzare l'esperienza nel MainLayout componente. Poiché l'helper tag di ambiente (ad esempio , <environment include="Production">...</environment>) non è supportato nei Razor componenti, l'esempio seguente inserisce per configurare i IHostEnvironment messaggi di errore per ambienti diversi.

Nella parte superiore di MainLayout.razor:

@inject IHostEnvironment HostEnvironment

Creare o modificare il markup dell'interfaccia utente degli Blazor errori:

<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>

In un'app Blazor Server personalizzare l'esperienza nel Pages/_Host.cshtml file. Nell'esempio seguente viene usato l'helper tag di ambiente per configurare i messaggi di errore per ambienti diversi.

In un'app Blazor Server personalizzare l'esperienza nel Pages/_Layout.cshtml file. Nell'esempio seguente viene usato l'helper tag di ambiente per configurare i messaggi di errore per ambienti diversi.

In un'app Blazor Server personalizzare l'esperienza nel Pages/_Host.cshtml file. Nell'esempio seguente viene usato l'helper tag di ambiente per configurare i messaggi di errore per ambienti diversi.

Creare o modificare il markup dell'interfaccia utente degli Blazor errori:

<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'elemento blazor-error-ui è in genere nascosto a causa della presenza dello display: none stile della blazor-error-ui classe CSS nel foglio di stile generato automaticamente dell'app. Quando si verifica un errore, il framework si applica display: block all'elemento .

L'elemento blazor-error-ui è in genere nascosto a causa della presenza dello display: none stile della blazor-error-ui classe CSS nel foglio di stile del sito nella wwwroot/css cartella . Quando si verifica un errore, il framework si applica display: block all'elemento .

Questa sezione si applica a Blazor Web Apps che opera su un circuito.

Questa sezione si applica alle Blazor Server app.

Errori dettagliati per il Razor rendering lato server del componente

Questa sezione si applica a Blazor Web Apps.

Usare l'opzione RazorComponentsServiceOptions.DetailedErrors per controllare la produzione di informazioni dettagliate sugli errori per Razor il rendering lato server dei componenti. Il valore predefinito è false.

Nell'esempio seguente vengono attivati errori dettagliati:

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

Per gli approcci alla gestione globale delle eccezioni, vedere le sezioni seguenti:

• Limiti di errore: si applica a tutte le Blazor app.
• Gestione alternativa delle eccezioni globali: si applica a Blazor Server, Blazor WebAssemblye Blazor Web Apps (8.0 o versione successiva) che adottano una modalità di rendering interattiva globale.

Limiti di errore

I limiti degli errori offrono un approccio pratico per la gestione delle eccezioni. Componente ErrorBoundary :

• Esegue il rendering del contenuto figlio quando non si è verificato un errore.
• Esegue il rendering dell'interfaccia utente degli errori quando un'eccezione non gestita viene generata da qualsiasi componente all'interno del limite di errore.

Per definire un limite di errore, usare il componente per eseguire il ErrorBoundary wrapping di uno o più componenti. Il limite di errore gestisce le eccezioni non gestite generate dai componenti di cui esegue il wrapping.

<ErrorBoundary>
    ...
</ErrorBoundary>

Per implementare un limite di errore in modo globale, aggiungere il limite intorno al contenuto del corpo del layout principale dell'app.

In MainLayout.razor:

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

In Blazor Web Apps con il limite di errore applicato solo a un componente statico MainLayout , il limite è attivo solo durante il rendering statico lato server (SSR statico). Il limite non viene attivato solo perché un componente più in basso nella gerarchia dei componenti è interattivo.

Non è possibile applicare una modalità di rendering interattiva al MainLayout componente perché il parametro del Body componente è un RenderFragment delegato, ovvero codice arbitrario e non può essere serializzato. Per abilitare l'interattività su larga scala per il MainLayout componente e i rest componenti più in basso nella gerarchia dei componenti, l'app deve adottare una modalità di rendering interattiva globale applicando la modalità di rendering interattiva alle istanze del HeadOutlet componente e Routes nel componente radice dell'app, che in genere è il App componente. L'esempio seguente adotta la modalità di rendering Interactive Server (InteractiveServer) a livello globale.

In Components/App.razor:

<HeadOutlet @rendermode="InteractiveServer" />

...

<Routes @rendermode="InteractiveServer" />

Se si preferisce non abilitare l'interattività globale, posizionare il limite di errore più lontano dalla gerarchia dei componenti. I concetti importanti da tenere presente sono che ovunque si trovi il limite di errore:

• Se il componente in cui viene posizionato il limite di errore non è interattivo, il limite di errore è in grado di attivarsi solo nel server durante il ssr statico. Ad esempio, il limite può essere attivato quando viene generato un errore in un metodo del ciclo di vita del componente, ma non per un evento attivato dall'interattività dell'utente all'interno del componente, ad esempio un errore generato da un gestore di clic del pulsante.
• Se il componente in cui viene posizionato il limite di errore è interattivo, il limite di errore è in grado di attivare per i componenti interattivi a capo.

Si consideri l'esempio seguente, in cui un'eccezione generata da un componente contatore incorporato viene intercettata da un limite di errore nel Home componente, che adotta una modalità di rendering interattiva.

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>

Si consideri l'esempio seguente, in cui un'eccezione generata da un componente contatore incorporato viene intercettata da un limite di errore nel Home componente.

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>

Se l'eccezione non gestita viene generata per un currentCount valore superiore a cinque:

• L'errore viene registrato normalmente (System.InvalidOperationException: Current count is too big!).
• L'eccezione viene gestita dal limite di errore.
• Il rendering dell'interfaccia utente dell'errore predefinito viene eseguito dal limite di errore.

Il componente esegue il ErrorBoundary rendering di un elemento vuoto <div> usando la blazor-error-boundary classe CSS per il relativo contenuto di errore. I colori, il testo e l'icona per l'interfaccia utente predefinita sono definiti nel foglio di stile dell'app nella wwwroot cartella, quindi è possibile personalizzare l'interfaccia utente dell'errore.

Per modificare il contenuto di errore predefinito:

• Eseguire il wrapping dei componenti del limite di errore nella ChildContent proprietà .
• Impostare la ErrorContent proprietà sul contenuto dell'errore.

Nell'esempio seguente viene eseguito il wrapping del EmbeddedCounter componente e viene fornito contenuto di errore personalizzato:

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

Per l'esempio precedente, il foglio di stile dell'app include presumibilmente una errorUI classe CSS per applicare uno stile al contenuto. Il rendering del contenuto dell'errore ErrorContent viene eseguito dalla proprietà senza un elemento a livello di blocco. Un elemento a livello di blocco, ad esempio una divisione (<div>) o un elemento di paragrafo (<p>), può eseguire il wrapping del markup del contenuto degli errori, ma non è obbligatorio.

Facoltativamente, usare il contesto (@context) di per ottenere i dati sugli ErrorContent errori:

<ErrorContent>
    @context.HelpLink
</ErrorContent>

Può ErrorContent anche denominare il contesto. Nell'esempio seguente il contesto è denominato exception:

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

Se il limite di errore viene definito nel layout dell'app, l'interfaccia utente dell'errore viene visualizzata indipendentemente dalla pagina a cui si sposta l'utente dopo che si verifica l'errore. È consigliabile definire in modo ristretto i limiti degli errori nella maggior parte degli scenari. Se si definisce un ambito generale di un limite di errore, è possibile ripristinarlo in uno stato non di errore negli eventi di spostamento di pagina successivi chiamando il metodo del limite di Recover errore.

In MainLayout.razor:

• Aggiungere un campo per l'oggetto ErrorBoundary per acquisire un riferimento a esso con la direttiva attribute @ref .
• Nel metodo del OnParameterSet ciclo di vita è possibile attivare un ripristino sul limite di errore con per Recover cancellare l'errore quando l'utente passa a un componente diverso.

...

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

...

@code {
    private ErrorBoundary? errorBoundary;

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

Per evitare il ciclo infinito in cui il recupero esegue semplicemente il rerendere un componente che genera nuovamente l'errore, non chiamare Recover dalla logica di rendering. Chiama Recover solo quando:

• L'utente esegue un movimento dell'interfaccia utente, ad esempio selezionando un pulsante per indicare che desidera ripetere una procedura o quando l'utente passa a un nuovo componente.
• Logica aggiuntiva che esegue cancella anche l'eccezione. Quando il componente viene rerendered, l'errore non viene eseguito di nuovo.

L'esempio seguente consente all'utente di eseguire il ripristino dall'eccezione con un pulsante:

<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;
}

È anche possibile sottoclasse ErrorBoundary per l'elaborazione personalizzata eseguendo l'override di OnErrorAsync. L'esempio seguente registra semplicemente l'errore, ma è possibile implementare qualsiasi codice di gestione degli errori desiderato. È possibile rimuovere la riga che restituisce se CompletedTask il codice attende un'attività asincrona.

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'esempio precedente può essere implementato anche come 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;
    }
}

Una delle implementazioni precedenti usate in un componente:

<CustomErrorBoundary>
    ...
</CustomErrorBoundary>

Gestione alternativa delle eccezioni globali

L'approccio descritto in questa sezione si applica a Blazor Server, Blazor WebAssemblye Blazor Web Appche adottano una modalità di rendering interattiva globale (InteractiveServer, InteractiveWebAssemblyo InteractiveAuto). L'approccio non funziona con Blazor Web Apps che adotta le modalità di rendering per pagina/componente o il rendering statico lato server (SSR statico) perché l'approccio si basa su un CascadingValue/CascadingParameter, che non funziona attraverso i limiti della modalità di rendering o con componenti che adottano SSR statico.

Un'alternativa all'uso dei limiti di errore (ErrorBoundary) consiste nel passare un componente di errore personalizzato come componente CascadingValue ai componenti figlio. Un vantaggio dell'uso di un componente rispetto all'uso di un servizio inserito o di un'implementazione di logger personalizzata è che un componente a catena può eseguire il rendering del contenuto e applicare stili CSS quando si verifica un errore.

L'esempio di componente seguente ProcessError registra semplicemente gli errori, ma i metodi del componente possono elaborare gli errori in qualsiasi modo richiesto dall'app, incluso l'uso di più metodi di elaborazione degli errori.

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();
    }
}

Quando si usa questo approccio in un Blazor Web App, aprire il Routes componente ed eseguire il wrapping del Router componente (<Router>...</Router>) con il ProcessError componente . Ciò consente al ProcessError componente di propagarsi verso il basso a qualsiasi componente dell'app in cui il ProcessError componente viene ricevuto come .CascadingParameter

In Routes.razor:

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

Quando si usa questo approccio in un'app Blazor Server o Blazor WebAssembly , aprire il componente, eseguire il App wrapping del Router componente (<Router>...</Router>) con il ProcessError componente . Ciò consente al ProcessError componente di propagarsi verso il basso a qualsiasi componente dell'app in cui il ProcessError componente viene ricevuto come .CascadingParameter

In App.razor:

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

Per elaborare gli errori in un componente:

• Designare il ProcessError componente come oggetto CascadingParameter nel @code blocco . In un componente di esempio Counter in un'app basata su un Blazor modello di progetto aggiungere la proprietà seguente ProcessError :

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

• Chiamare un metodo di elaborazione degli errori in qualsiasi catch blocco con un tipo di eccezione appropriato. Il componente di esempio ProcessError offre un solo LogError metodo, ma il componente di elaborazione degli errori può fornire un numero qualsiasi di metodi di elaborazione degli errori per soddisfare i requisiti di elaborazione degli errori alternativi in tutta l'app. L'esempio di blocco di componenti @code seguente Counter include il ProcessError parametro a catena e intercettare un'eccezione per la registrazione quando il conteggio è maggiore di cinque:

  @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);
          }
      }
  }
  

Errore registrato:

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

Se il LogError metodo partecipa direttamente al rendering, ad esempio la visualizzazione di una barra dei messaggi di errore personalizzata o la modifica degli stili CSS degli elementi di cui è stato eseguito il rendering, chiamare StateHasChanged alla fine del LogError metodo per ripristinare l'interfaccia utente.

Poiché gli approcci in questa sezione gestiscono gli errori con un'istruzione, la connessione di SignalR un'app try-catch tra il client e il server non viene interrotta quando si verifica un errore e il circuito rimane attivo. Altre eccezioni non gestite rimangono fatali per un circuito. Per altre informazioni, vedere la sezione relativa alla reazione di un circuito a eccezioni non gestite.

Un'app può usare un componente di elaborazione degli errori come valore a catena per elaborare gli errori in modo centralizzato.

Il componente seguente ProcessError viene passato come oggetto CascadingValue ai componenti figlio. L'esempio seguente registra semplicemente l'errore, ma i metodi del componente possono elaborare gli errori in qualsiasi modo richiesto dall'app, incluso l'uso di più metodi di elaborazione degli errori. Un vantaggio dell'uso di un componente rispetto all'uso di un servizio inserito o di un'implementazione di logger personalizzata è che un componente a catena può eseguire il rendering del contenuto e applicare stili CSS quando si verifica un errore.

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);
    }
}

App Nel componente eseguire il wrapping del Router componente con il ProcessError componente . Ciò consente al ProcessError componente di propagarsi verso il basso a qualsiasi componente dell'app in cui il ProcessError componente viene ricevuto come .CascadingParameter

App.razor:

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

Per elaborare gli errori in un componente:

• Designare il ProcessError componente come nel CascadingParameter @code blocco:

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

• Chiamare un metodo di elaborazione degli errori in qualsiasi catch blocco con un tipo di eccezione appropriato. Il componente di esempio ProcessError offre un solo LogError metodo, ma il componente di elaborazione degli errori può fornire un numero qualsiasi di metodi di elaborazione degli errori per soddisfare i requisiti di elaborazione degli errori alternativi in tutta l'app.

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

Usando il componente e LogError il metodo di esempio ProcessError precedenti, la console degli strumenti di sviluppo del browser indica l'errore bloccato registrato:

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

Se il LogError metodo partecipa direttamente al rendering, ad esempio la visualizzazione di una barra dei messaggi di errore personalizzata o la modifica degli stili CSS degli elementi di cui è stato eseguito il rendering, chiamare StateHasChanged alla fine del LogError metodo per ripristinare l'interfaccia utente.

Poiché gli approcci in questa sezione gestiscono gli errori con un'istruzionetry-catch, la connessione di SignalR un'app Blazor tra il client e il server non viene interrotta quando si verifica un errore e il circuito rimane attivo. Qualsiasi eccezione non gestita è irreversibile per un circuito. Per altre informazioni, vedere la sezione relativa alla reazione di un circuito a eccezioni non gestite.

Se si verifica un'eccezione non gestita, l'eccezione viene registrata nelle ILogger istanze configurate nel contenitore del servizio. Blazor output della console di log delle app con il provider di registrazione della console. Prendere in considerazione la registrazione in un percorso nel server (o nell'API Web back-end per le app lato client) con un provider che gestisce le dimensioni del log e la rotazione dei log. In alternativa, l'app può usare un servizio APM (Application Performance Management), ad esempio app Azure lication Insights (Monitoraggio di Azure).

Durante lo sviluppo in un'app Blazor che opera su un circuito, l'app in genere invia i dettagli completi delle eccezioni alla console del browser per facilitare il debug. Nell'ambiente di produzione, gli errori dettagliati non vengono inviati ai client, ma i dettagli completi di un'eccezione vengono registrati nel server.

È necessario decidere quali eventi imprevisti registrare e il livello di gravità degli eventi imprevisti registrati. Gli utenti ostili potrebbero essere in grado di attivare deliberatamente gli errori. Ad esempio, non registrare un evento imprevisto da un errore in cui viene fornito un sconosciuto ProductId nell'URL di un componente che visualizza i dettagli del prodotto. Non tutti gli errori devono essere considerati come eventi imprevisti per la registrazione.

Per altre informazioni, vedere gli articoli seguenti:

• Registrazione di ASP.NET Core Blazor
• Gestire gli errori in ASP.NET Core*
• Creare API Web con ASP.NET Core

*Si applica alle app lato Blazor server e ad altre app ASP.NET Core lato server che sono app back-end dell'API Web per Blazor. Le app sul lato client possono intercettare e inviare informazioni sugli errori sul client a un'API Web, che registra le informazioni sull'errore a un provider di registrazione permanente.

Se si verifica un'eccezione non gestita, l'eccezione viene registrata nelle ILogger istanze configurate nel contenitore del servizio. Blazor output della console di log delle app con il provider di registrazione della console. Valutare la possibilità di accedere a una posizione più permanente nel server inviando informazioni sugli errori a un'API Web back-end che usa un provider di registrazione con gestione delle dimensioni dei log e rotazione dei log. In alternativa, l'app per le API Web back-end può usare un servizio APM (Application Performance Management), ad esempio app Azure lication Insights (Monitoraggio di Azure)†, per registrare le informazioni sugli errori ricevute dai client.

È necessario decidere quali eventi imprevisti registrare e il livello di gravità degli eventi imprevisti registrati. Gli utenti ostili potrebbero essere in grado di attivare deliberatamente gli errori. Ad esempio, non registrare un evento imprevisto da un errore in cui viene fornito un sconosciuto ProductId nell'URL di un componente che visualizza i dettagli del prodotto. Non tutti gli errori devono essere considerati come eventi imprevisti per la registrazione.

Per altre informazioni, vedere gli articoli seguenti:

• Registrazione di ASP.NET Core Blazor
• Gestire gli errori in ASP.NET Core*
• Creare API Web con ASP.NET Core

† Funzionalità di Application Insights per supportare le app sul lato client e il supporto del framework nativo Blazor per Google Analytics potrebbero diventare disponibili nelle versioni future di queste tecnologie. Per altre informazioni, vedere Supporto di App Insights sul Blazor lato client WASM (microsoft/ApplicationInsights-dotnet #2143) e analisi Web e diagnostica (include collegamenti alle implementazioni della community) (dotnet/aspnetcore #5461). Nel frattempo, un'app lato client può usare Application Insights JavaScript SDK con JS interoperabilità per registrare gli errori direttamente in Application Insights da un'app lato client.

*Si applica alle app di base ASP.NET lato server che sono app back-end dell'API Web per Blazor le app. Le app sul lato client intercettare e inviare informazioni sugli errori a un'API Web, che registra le informazioni sull'errore a un provider di registrazione permanente.

• Creazione di un'istanza del componente
• Metodi relativi al ciclo di vita
• Logica di rendering
• Gestori eventi
• Eliminazione dei componenti
• Interoperabilità JavaScript
• Prerendering

• Creazione di un'istanza del componente
• Metodi relativi al ciclo di vita
• Logica di rendering
• Gestori eventi
• Eliminazione dei componenti
• Interoperabilità JavaScript
• Prerendering

@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);
    }
}

Prerendering

Razor Per impostazione predefinita, i componenti vengono prerenderati in modo che il markup HTML sottoposto a rendering venga restituito come parte della richiesta HTTP iniziale dell'utente.

In un'app Blazor che opera su un circuito, il prerendering funziona in base a:

• Creazione di un nuovo circuito per tutti i componenti prerisorsi che fanno parte della stessa pagina.
• Generazione del codice HTML iniziale.
• Considerando il circuito come disconnected finché il browser dell'utente non stabilisce una SignalR connessione allo stesso server. Quando viene stabilita la connessione, l'interattività sul circuito viene ripresa e il markup HTML dei componenti viene aggiornato.

Per i componenti lato client prerenderati, il prerendering funziona in base a:

• Generazione di codice HTML iniziale nel server per tutti i componenti prerenderati che fanno parte della stessa pagina.
• Rendere interattivo il componente sul client dopo che il browser ha caricato il codice compilato dell'app e il runtime .NET (se non è già stato caricato) in background.

Se un componente genera un'eccezione non gestita durante la pre-esecuzione, ad esempio, durante un metodo del ciclo di vita o nella logica di rendering:

• In un'app Blazor che opera su un circuito, l'eccezione è irreversibile per il circuito. Per i componenti lato client prerenderati, l'eccezione impedisce il rendering del componente.
• L'eccezione viene generata dallo stack di chiamate da ComponentTagHelper.

In circostanze normali in cui il prerendering non riesce, continuare a compilare ed eseguire il rendering del componente non ha senso perché non è possibile eseguire il rendering di un componente funzionante.

Per tollerare errori che possono verificarsi durante la pre-esecuzione, è necessario inserire la logica di gestione degli errori all'interno di un componente che potrebbe generare eccezioni. Usare try-catch istruzioni con la gestione e la registrazione degli errori. Anziché eseguire il wrapping di in un'istruzione try-catch , posizionare la ComponentTagHelper logica di gestione degli errori nel componente sottoposto a rendering da ComponentTagHelper.

• Gestire le eccezioni rilevate al di fuori del ciclo di vita di un Razor componente
• Registrazione di ASP.NET Core Blazor
• Gestire gli errori in ASP.NET Core†
• Creare API Web con ASP.NET Core
• Blazorrepository GitHub di esempi () (dotnet/blazor-samplescome scaricare)

• Registrazione di ASP.NET Core Blazor
• Gestire gli errori in ASP.NET Core†
• Creare API Web con ASP.NET Core
• Blazorrepository GitHub di esempi () (dotnet/blazor-samplescome scaricare)