ASP.NET ciclo di vita dei componenti principali Razor

Questo articolo illustra il ciclo di vita dei componenti di Razor base ASP.NET e come usare gli eventi del ciclo di vita.

Eventi del ciclo di vita

Il Razor componente elabora Razor gli eventi del ciclo di vita dei componenti in un set di metodi del ciclo di vita sincroni e asincroni. È possibile eseguire l'override dei metodi del ciclo di vita per eseguire operazioni aggiuntive nei componenti durante l'inizializzazione e il rendering dei componenti.

Questo articolo semplifica l'elaborazione degli eventi del ciclo di vita dei componenti per chiarire la logica complessa del framework e non copre tutte le modifiche apportate negli anni. Potrebbe essere necessario accedere all'origine di riferimento per integrare l'elaborazione ComponentBase di eventi personalizzati con Blazorl'elaborazione degli eventi del ciclo di vita. I commenti di codice nell'origine di riferimento includono osservazioni aggiuntive sull'elaborazione degli eventi del ciclo di vita che non vengono visualizzati in questo articolo o nella documentazione dell'API.

Nota

I collegamenti della documentazione all'origine del riferimento .NET in genere caricano il ramo predefinito del repository, che rappresenta lo sviluppo corrente per la versione successiva di .NET. Per selezionare un tag per una versione specifica, usare l'elenco a discesa Switch branches or tags. Per altre informazioni, vedere How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205) (Come selezionare un tag di versione del codice sorgente di ASP.NET - dotnet/AspNetCore.Docs #26205).

I diagrammi semplificati seguenti illustrano Razor l'elaborazione degli eventi del ciclo di vita dei componenti. I metodi C# associati agli eventi del ciclo di vita sono definiti con esempi nelle sezioni seguenti di questo articolo.

Eventi del ciclo di vita dei componenti:

1. Se il rendering del componente viene eseguito per la prima volta in una richiesta:
   • Creare l'istanza del componente.
   • Eseguire l'inserimento di proprietà.
   • Chiamare OnInitialized{Async}. Se viene restituito un elemento incompleto Task , viene Task atteso e quindi il componente viene ririsolto. Il metodo sincrono viene chiamato prima del metodo asincrono.
2. Chiamare OnParametersSet{Async}. Se viene restituito un elemento incompleto Task , viene Task atteso e quindi il componente viene ririsolto. Il metodo sincrono viene chiamato prima del metodo asincrono.
3. Eseguire il rendering per tutte le operazioni sincrone e complete Task.

Nota

Le azioni asincrone eseguite negli eventi del ciclo di vita potrebbero non essere completate prima del rendering di un componente. Per altre informazioni, vedere la sezione Gestire azioni asincrone incomplete al rendering più avanti in questo articolo.

Viene eseguito il rendering di un componente padre prima dei relativi componenti figlio perché il rendering determina quali elementi figlio sono presenti. Se viene utilizzata l'inizializzazione sincrona del componente padre, l'inizializzazione padre viene garantita per prima. Se viene utilizzata l'inizializzazione asincrona dei componenti padre, l'ordine di completamento dell'inizializzazione dei componenti padre e figlio non può essere determinato perché dipende dal codice di inizializzazione in esecuzione.

Elaborazione di eventi DOM:

1. Viene eseguito il gestore eventi.
2. Se viene restituito un elemento incompleto Task , viene Task atteso e quindi il componente viene ririsolto.
3. Eseguire il rendering per tutte le operazioni sincrone e complete Task.

Ciclo Render di vita:

1. Evitare ulteriori operazioni di rendering sul componente quando vengono soddisfatte entrambe le condizioni seguenti:
   • Non è il primo rendering.
   • ShouldRender restituisce false.
2. Compilare il diff dell'albero di rendering (differenza) ed eseguire il rendering del componente.
3. Attendere il DOM da aggiornare.
4. Chiamare OnAfterRender{Async}. Il metodo sincrono viene chiamato prima del metodo asincrono.

Le chiamate degli sviluppatori per StateHasChanged ottenere un rerender. Per altre informazioni, vedere Rendering dei componenti di ASP.NET CoreRazor.

Quando i parametri sono impostati (SetParametersAsync)

SetParametersAsync imposta i parametri forniti dall'elemento padre del componente nell'albero di rendering o dai parametri di route.

Il parametro del ParameterView metodo contiene il set di valori dei parametri del componente per il componente ogni volta SetParametersAsync che viene chiamato. Eseguendo l'override del metodo, il SetParametersAsync codice dello sviluppatore può interagire direttamente con ParameterViewi parametri di .

L'implementazione predefinita di SetParametersAsync imposta il valore di ogni proprietà con l'attributo [Parameter] o [CascadingParameter] con un valore corrispondente in ParameterView. I parametri che non hanno un valore corrispondente in ParameterView vengono lasciati invariati.

In genere, il codice deve chiamare il metodo della classe base (await base.SetParametersAsync(parameters);) quando si esegue l'override di SetParametersAsync. Negli scenari avanzati, il codice dello sviluppatore può interpretare i valori dei parametri in ingresso in qualsiasi modo richiesto non richiamando il metodo della classe base. Ad esempio, non è necessario assegnare i parametri in ingresso alle proprietà della classe . Tuttavia, è necessario fare riferimento all'origine di ComponentBase riferimento quando si struttura il codice senza chiamare il metodo della classe di base perché chiama altri metodi del ciclo di vita e attiva il rendering in modo complesso.

Nota

I collegamenti della documentazione all'origine del riferimento .NET in genere caricano il ramo predefinito del repository, che rappresenta lo sviluppo corrente per la versione successiva di .NET. Per selezionare un tag per una versione specifica, usare l'elenco a discesa Switch branches or tags. Per altre informazioni, vedere How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205) (Come selezionare un tag di versione del codice sorgente di ASP.NET - dotnet/AspNetCore.Docs #26205).

Se si vuole basarsi sulla logica di inizializzazione e rendering di ComponentBase.SetParametersAsync ma non elaborare i parametri in ingresso, è possibile passare un oggetto vuoto ParameterView al metodo della classe base:

await base.SetParametersAsync(ParameterView.Empty);

Se i gestori eventi vengono forniti nel codice dello sviluppatore, annullare ilhook all'eliminazione. Per altre informazioni, vedere la sezione Eliminazione dei componenti con IDisposable e IAsyncDisposable .

Nell'esempio seguente, ParameterView.TryGetValue assegna il Param valore del parametro a value se l'analisi di un parametro di route per Param ha esito positivo. Quando value non nullè , il valore viene visualizzato dal componente.

Anche se la corrispondenza dei parametri di route non fa distinzione tra maiuscole e minuscole, TryGetValue corrisponde solo ai nomi dei parametri con distinzione tra maiuscole e minuscole nel modello di route. L'esempio seguente richiede l'uso di nel modello di /{Param?} route per ottenere il valore con TryGetValue, non /{param?}. Se /{param?} viene usato in questo scenario, TryGetValue restituisce false e message non è impostato su una message stringa.

SetParamsAsync.razor:

@page "/set-params-async/{Param?}"

<PageTitle>Set Parameters Async</PageTitle>

<h1>Set Parameters Async Example</h1>

<p>@message</p>

@code {
    private string message = "Not set";

    [Parameter]
    public string? Param { get; set; }

    public override async Task SetParametersAsync(ParameterView parameters)
    {
        if (parameters.TryGetValue<string>(nameof(Param), out var value))
        {
            if (value is null)
            {
                message = "The value of 'Param' is null.";
            }
            else
            {
                message = $"The value of 'Param' is {value}.";
            }
        }

        await base.SetParametersAsync(parameters);
    }
}

Inizializzazione dei componenti (OnInitialized{Async})

OnInitialized e OnInitializedAsync vengono utilizzati esclusivamente per inizializzare un componente per l'intera durata dell'istanza del componente. I valori dei parametri e le modifiche al valore dei parametri non devono influire sull'inizializzazione eseguita in questi metodi. Ad esempio, il caricamento di opzioni statiche in un elenco a discesa che non cambia per la durata del componente e che non dipende dai valori dei parametri viene eseguito in uno di questi metodi del ciclo di vita. Se i valori dei parametri o le modifiche apportate ai valori dei parametri influiscono sullo stato del componente, usare OnParametersSet{Async} invece .

Questi metodi vengono richiamati quando il componente viene inizializzato dopo aver ricevuto i parametri iniziali in SetParametersAsync. Il metodo sincrono viene chiamato prima del metodo asincrono.

Se viene utilizzata l'inizializzazione sincrona dei componenti padre, l'inizializzazione padre viene garantita prima dell'inizializzazione del componente figlio. Se viene utilizzata l'inizializzazione asincrona dei componenti padre, l'ordine di completamento dell'inizializzazione dei componenti padre e figlio non può essere determinato perché dipende dal codice di inizializzazione in esecuzione.

Per un'operazione sincrona, eseguire l'override OnInitializeddi :

OnInit.razor:

@page "/on-init"

<PageTitle>On Initialized</PageTitle>

<h1>On Initialized Example</h1>

<p>@message</p>

@code {
    private string? message;

    protected override void OnInitialized() => 
        message = $"Initialized at {DateTime.Now}";
}

Per eseguire un'operazione asincrona, eseguire l'override OnInitializedAsync e usare l'operatore await :

protected override async Task OnInitializedAsync()
{
    await ...
}

Se viene usata una classe base personalizzata con la logica di inizializzazione personalizzata, chiamare OnInitializedAsync sulla classe base:

protected override async Task OnInitializedAsync()
{
    await ...

    await base.OnInitializedAsync();
}

Non è necessario chiamare ComponentBase.OnInitializedAsync a meno che non venga usata una classe di base personalizzata con logica personalizzata. Per altre informazioni, vedere la sezione Metodi del ciclo di vita della classe base.

Blazor app che prerendere il contenuto sul server chiamano OnInitializedAsync due volte:

• Una volta quando il rendering del componente viene inizialmente eseguito in modo statico come parte della pagina.
• Seconda volta che il browser esegue il rendering del componente.

Per impedire l'esecuzione del codice OnInitializedAsync dello sviluppatore due volte durante la pre-esecuzione, vedere la sezione Riconnessione con stato dopo il prerendering . Il contenuto della sezione è incentrato sulla Blazor Web Appriconnessione con stato SignalRe s. Per mantenere lo stato durante l'esecuzione del codice di inizializzazione durante la pre-esecuzione, vedere Prerender ASP.NET Componenti di baseRazor.

Mentre un'app Blazor esegue la pre-gestione, alcune azioni, ad esempio la chiamata a JavaScript (JS interoperabilità), non sono possibili. Potrebbe essere necessario eseguire il rendering dei componenti in modo diverso quando viene eseguito il pre-riavvio. Per altre informazioni, vedere la sezione Prerendering with JavaScript interop (Prerendering with JavaScript interop ).

Se i gestori eventi vengono forniti nel codice dello sviluppatore, annullare ilhook all'eliminazione. Per altre informazioni, vedere la sezione Eliminazione dei componenti conIAsyncDisposableIDisposable .

Usare il rendering in streaming con rendering statico lato server (SSR statico) o prerendering per migliorare l'esperienza utente per i componenti che eseguono attività asincrone a esecuzione prolungata in OnInitializedAsync per il rendering completo. Per altre informazioni, vedere Rendering dei componenti di ASP.NET CoreRazor.

Dopo aver impostato i parametri (OnParametersSet{Async})

OnParametersSet o OnParametersSetAsync vengono chiamati:

• Dopo l'inizializzazione del componente in OnInitialized o OnInitializedAsync.

• Quando il componente padre esegue il rerender e fornisce:

  • Tipi non modificabili noti o primitivi quando almeno un parametro è stato modificato.
  • Parametri tipizzato complesso. Il framework non è in grado di stabilire se i valori di un parametro tipizzato complesso sono stati modificati internamente, quindi il framework considera sempre il set di parametri come modificato quando sono presenti uno o più parametri tipizzati complessi.

  Per altre informazioni sulle convenzioni di rendering, vedere rendering dei componenti di Razor base ASP.NET.

Il metodo sincrono viene chiamato prima del metodo asincrono.

I metodi possono essere richiamati anche se i valori dei parametri non sono stati modificati. Questo comportamento sottolinea la necessità per gli sviluppatori di implementare logica aggiuntiva all'interno dei metodi per verificare se i valori dei parametri sono stati effettivamente modificati prima di inizializzare nuovamente i dati o lo stato dipendenti da tali parametri.

Per il componente di esempio seguente, passare alla pagina del componente in un URL:

• Con una data di inizio ricevuta da StartDate: /on-parameters-set/2021-03-19
• Senza una data di inizio, dove StartDate viene assegnato un valore dell'ora locale corrente: /on-parameters-set

Nota

In una route del componente non è possibile vincolare entrambi un DateTime parametro con il vincolo datetime di route e rendere il parametro facoltativo. Di conseguenza, il componente seguente OnParamsSet usa due @page direttive per gestire il routing con e senza un segmento di data specificato nell'URL.

OnParamsSet.razor:

@page "/on-params-set"
@page "/on-params-set/{StartDate:datetime}"

<PageTitle>On Parameters Set</PageTitle>

<h1>On Parameters Set Example</h1>

<p>
    Pass a datetime in the URI of the browser's address bar. 
    For example, add <code>/1-1-2024</code> to the address.
</p>

<p>@message</p>

@code {
    private string? message;

    [Parameter]
    public DateTime StartDate { get; set; }

    protected override void OnParametersSet()
    {
        if (StartDate == default)
        {
            StartDate = DateTime.Now;

            message = $"No start date in URL. Default value applied " +
                $"(StartDate: {StartDate}).";
        }
        else
        {
            message = $"The start date in the URL was used " +
                $"(StartDate: {StartDate}).";
        }
    }
}

Il lavoro asincrono quando si applicano parametri e valori di proprietà deve verificarsi durante l'evento del OnParametersSetAsync ciclo di vita:

protected override async Task OnParametersSetAsync()
{
    await ...
}

Se viene usata una classe base personalizzata con la logica di inizializzazione personalizzata, chiamare OnParametersSetAsync sulla classe base:

protected override async Task OnParametersSetAsync()
{
    await ...

    await base.OnParametersSetAsync();
}

Non è necessario chiamare ComponentBase.OnParametersSetAsync a meno che non venga usata una classe di base personalizzata con logica personalizzata. Per altre informazioni, vedere la sezione Metodi del ciclo di vita della classe base.

Se i gestori eventi vengono forniti nel codice dello sviluppatore, annullare ilhook all'eliminazione. Per altre informazioni, vedere la sezione Eliminazione dei componenti conIAsyncDisposableIDisposable .

Per altre informazioni sui parametri e i vincoli di route, vedere ASP.NET routing e navigazione coreBlazor.

Per un esempio di implementazione SetParametersAsync manuale per migliorare le prestazioni in alcuni scenari, vedere ASP.NET Procedure consigliate per le prestazioni principaliBlazor.

Dopo il rendering del componente (OnAfterRender{Async})

OnAfterRender e OnAfterRenderAsync vengono richiamati dopo il rendering interattivo di un componente e l'interfaccia utente ha terminato l'aggiornamento(ad esempio, dopo l'aggiunta di elementi al DOM del browser). I riferimenti a elementi e componenti vengono popolati a questo punto. Usare questa fase per eseguire passaggi di inizializzazione aggiuntivi con il contenuto sottoposto a rendering, ad esempio JS le chiamate di interoperabilità che interagiscono con gli elementi DOM sottoposti a rendering. Il metodo sincrono viene chiamato prima del metodo asincrono.

Questi metodi non vengono richiamati durante il prerendering o il rendering statico lato server (SSR statico) nel server perché tali processi non sono collegati a un DOM del browser attivo e sono già stati completati prima dell'aggiornamento del DOM.

Per OnAfterRenderAsync, il componente non esegue automaticamente il rerender dopo il completamento di qualsiasi operazione restituita Task per evitare un ciclo di rendering infinito.

Parametro firstRender per OnAfterRender e OnAfterRenderAsync:

• È impostato sulla true prima volta che viene eseguito il rendering dell'istanza del componente.
• Può essere usato per garantire che il lavoro di inizializzazione venga eseguito una sola volta.

AfterRender.razor:

@page "/after-render"
@inject ILogger<AfterRender> Logger 

<PageTitle>After Render</PageTitle>

<h1>After Render Example</h1>

<p>
    <button @onclick="HandleClick">Log information (and trigger a render)</button>
</p>

<p>Study logged messages in the console.</p>

@code {
    protected override void OnAfterRender(bool firstRender) =>
        Logger.LogInformation("firstRender = {FirstRender}", firstRender);

    private void HandleClick() => Logger.LogInformation("HandleClick called");
}

L'esempio genera l'output AfterRender.razor seguente nella console quando viene caricata la pagina e il pulsante è selezionato:

OnAfterRender: firstRender = True
HandleClick called
OnAfterRender: firstRender = False

Il lavoro asincrono subito dopo il rendering deve verificarsi durante l'evento del OnAfterRenderAsync ciclo di vita:

protected override async Task OnAfterRenderAsync(bool firstRender)
{
    ...
}

Se viene usata una classe base personalizzata con la logica di inizializzazione personalizzata, chiamare OnAfterRenderAsync sulla classe base:

protected override async Task OnAfterRenderAsync(bool firstRender)
{
    ...

    await base.OnAfterRenderAsync(firstRender);
}

Non è necessario chiamare ComponentBase.OnAfterRenderAsync a meno che non venga usata una classe di base personalizzata con logica personalizzata. Per altre informazioni, vedere la sezione Metodi del ciclo di vita della classe base.

Anche se si restituisce un oggetto Task da OnAfterRenderAsync, il framework non pianifica un ulteriore ciclo di rendering per il componente al termine dell'attività. Ciò consente di evitare un ciclo di rendering infinito. Questo è diverso dagli altri metodi del ciclo di vita, che pianificano un ciclo di rendering successivo al completamento di un oggetto restituito Task .

OnAfterRender e OnAfterRenderAsync non vengono chiamati durante il processo di pre-esecuzione nel server. I metodi vengono chiamati quando il rendering del componente viene eseguito in modo interattivo dopo il prerendering. Quando l'app esegue il prerenders:

1. Il componente viene eseguito sul server per produrre un markup HTML statico nella risposta HTTP. Durante questa fase, OnAfterRender e OnAfterRenderAsync non vengono chiamati.
2. Quando lo Blazor script (blazor.{server|webassembly|web}.js) viene avviato nel browser, il componente viene riavviato in modalità di rendering interattivo. Dopo il riavvio OnAfterRender di un componente e OnAfterRenderAsync viene chiamato perché l'app non è più nella fase di pre-esecuzione.

Se i gestori eventi vengono forniti nel codice dello sviluppatore, annullare ilhook all'eliminazione. Per altre informazioni, vedere la sezione Eliminazione dei componenti conIAsyncDisposableIDisposable .

Metodi del ciclo di vita della classe base

Quando si esegue l'override Blazordei metodi del ciclo di vita di , non è necessario chiamare i metodi del ciclo di vita della classe base per ComponentBase. Tuttavia, un componente deve chiamare un metodo del ciclo di vita della classe base sottoposto a override nelle situazioni seguenti:

• Quando si esegue l'override ComponentBase.SetParametersAsyncdi , await base.SetParametersAsync(parameters); viene in genere richiamato perché il metodo della classe base chiama altri metodi del ciclo di vita e attiva il rendering in modo complesso. Per altre informazioni, vedere la sezione When parameters are set (SetParametersAsync).
• Se il metodo della classe base contiene la logica che deve essere eseguita. I consumer di librerie chiamano in genere metodi del ciclo di vita della classe base quando ereditano una classe base perché le classi di base della libreria hanno spesso una logica del ciclo di vita personalizzata da eseguire. Se l'app usa una classe base da una libreria, consultare la documentazione della libreria per indicazioni.

Nell'esempio base.OnInitialized(); seguente viene chiamato per assicurarsi che venga eseguito il metodo della classe di OnInitialized base. Senza la chiamata, BlazorRocksBase2.OnInitialized non viene eseguita.

BlazorRocks2.razor:

@page "/blazor-rocks-2"
@inherits BlazorRocksBase2
@inject ILogger<BlazorRocks2> Logger

<PageTitle>Blazor Rocks!</PageTitle>

<h1>Blazor Rocks! Example 2</h1>

<p>
    @BlazorRocksText
</p>

@code {
    protected override void OnInitialized()
    {
        Logger.LogInformation("Initialization code of BlazorRocks2 executed!");

        base.OnInitialized();
    }
}

BlazorRocksBase2.cs:

using Microsoft.AspNetCore.Components;

namespace BlazorSample;

public class BlazorRocksBase2 : ComponentBase
{
    [Inject]
    private ILogger<BlazorRocksBase2> Logger { get; set; } = default!;

    public string BlazorRocksText { get; set; } = "Blazor rocks the browser!";

    protected override void OnInitialized() =>
        Logger.LogInformation("Initialization code of BlazorRocksBase2 executed!");
}

Modifiche dello stato (StateHasChanged)

StateHasChanged notifica al componente che il relativo stato è stato modificato. Se applicabile, la chiamata StateHasChanged accoda un rerender che si verifica quando il thread principale dell'app è gratuito.

StateHasChanged viene chiamato automaticamente per EventCallback i metodi. Per altre informazioni sui callback degli eventi, vedere ASP.NET Gestione degli eventi coreBlazor.

Per altre informazioni sul rendering dei componenti e su quando chiamare StateHasChanged, incluso quando richiamarlo con ComponentBase.InvokeAsync, vedere ASP.NET rendering dei componenti principaliRazor.

Gestire azioni asincrone incomplete al rendering

Le azioni asincrone eseguite negli eventi del ciclo di vita potrebbero non essere state completate prima del rendering del componente. Gli oggetti potrebbero essere null o popolati in modo incompleto con dati durante l'esecuzione del metodo del ciclo di vita. Fornire la logica di rendering per verificare che gli oggetti siano inizializzati. Eseguire il rendering degli elementi dell'interfaccia utente segnaposto ,ad esempio un messaggio di caricamento, mentre gli oggetti sono null.

Nel componente seguente viene OnInitializedAsync eseguito l'override per fornire in modo asincrono i dati di classificazione dei film (movies). Quando movies è null, viene visualizzato un messaggio di caricamento all'utente. Al termine dell'oggetto Task restituito da OnInitializedAsync , il componente viene riabilito con lo stato aggiornato.

<h1>Sci-Fi Movie Ratings</h1>

@if (movies == null)
{
    <p><em>Loading...</em></p>
}
else
{
    <ul>
        @foreach (var movie in movies)
        {
            <li>@movie.Title &mdash; @movie.Rating</li>
        }
    </ul>
}

@code {
    private Movies[]? movies;

    protected override async Task OnInitializedAsync()
    {
        movies = await GetMovieRatings(DateTime.Now);
    }
}

Gestione degli errori

Per informazioni sulla gestione degli errori durante l'esecuzione del metodo del ciclo di vita, vedere Gestire gli errori nelle app ASP.NET CoreBlazor.

Riconnessione con stato dopo il prerendering

Quando si esegue la pre-distribuzione nel server, viene inizialmente eseguito il rendering statico di un componente come parte della pagina. Dopo che il browser stabilisce una SignalR connessione al server, il rendering del componente viene eseguito di nuovo e interattivo. Se il metodo del ciclo di vita per l'inizializzazione OnInitialized{Async} del componente è presente, il metodo viene eseguito due volte:

• Quando il componente viene prerenderato in modo statico.
• Dopo aver stabilito la connessione al server.

Ciò può comportare una modifica notevole dei dati visualizzati nell'interfaccia utente quando il rendering del componente viene infine eseguito. Per evitare questo comportamento, passare un identificatore per memorizzare nella cache lo stato durante la prerendering e recuperare lo stato dopo la pre-esecuzione del prerendering.

Il codice seguente illustra un WeatherForecastService oggetto che evita la modifica nella visualizzazione dei dati a causa del prerendering. Il valore atteso Delay (await Task.Delay(...)) simula un breve ritardo prima di restituire i dati dal GetForecastAsync metodo .

Aggiungere IMemoryCache servizi con AddMemoryCache nella raccolta di servizi nel file dell'app Program :

builder.Services.AddMemoryCache();

WeatherForecastService.cs:

using Microsoft.Extensions.Caching.Memory;

namespace BlazorSample;

public class WeatherForecastService(IMemoryCache memoryCache)
{
    private static readonly string[] summaries =
    [
        "Freezing", "Bracing", "Chilly", "Cool", "Mild",
        "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
    ];

    public IMemoryCache MemoryCache { get; } = memoryCache;

    public Task<WeatherForecast[]?> GetForecastAsync(DateOnly startDate)
    {
        return MemoryCache.GetOrCreateAsync(startDate, async e =>
        {
            e.SetOptions(new MemoryCacheEntryOptions
            {
                AbsoluteExpirationRelativeToNow =
                    TimeSpan.FromSeconds(30)
            });

            await Task.Delay(TimeSpan.FromSeconds(10));

            return Enumerable.Range(1, 5).Select(index => new WeatherForecast
            {
                Date = startDate.AddDays(index),
                TemperatureC = Random.Shared.Next(-20, 55),
                Summary = summaries[Random.Shared.Next(summaries.Length)]
            }).ToArray();
        });
    }
}

Per altre informazioni su , vedere ASP.NET Linee guida di baseBlazorSignalR.RenderMode

Il contenuto di questa sezione è incentrato sulla Blazor Web Appriconnessione con stato SignalRe s. Per mantenere lo stato durante l'esecuzione del codice di inizializzazione durante la pre-esecuzione, vedere Prerender ASP.NET Componenti di baseRazor.

Prerendering con interoperabilità JavaScript

Questa sezione si applica alle app lato server che prerendere Razor i componenti. La prerendering è descritta nei componenti Prerender ASP.NET CoreRazor.

Nota

Lo spostamento interno per il routing interattivo in Blazor Web Apps non comporta la richiesta di nuovo contenuto della pagina dal server. Di conseguenza, il prerendering non si verifica per le richieste di pagina interne. Se l'app adotta il routing interattivo, eseguire un ricaricamento a pagina completa per esempi di componenti che illustrano il comportamento di pre-esecuzione. Per altre informazioni, vedere Prerender ASP.NET Componenti di baseRazor.

Durante la pre-esecuzione, la chiamata a JavaScript (JS) non è possibile. Nell'esempio seguente viene illustrato come usare JS l'interoperabilità come parte della logica di inizializzazione di un componente in modo compatibile con la prerendering.

La funzione seguente scrollElementIntoView :

• Scorre fino all'elemento passato con scrollIntoView.
• Restituisce il valore della proprietà dell'elemento top dal getBoundingClientRect metodo .

window.scrollElementIntoView = (element) => {
  element.scrollIntoView();
  return element.getBoundingClientRect().top;
}

Dove IJSRuntime.InvokeAsync chiama la JS funzione nel codice del componente, ElementReference viene usato solo in OnAfterRenderAsync e non in alcun metodo del ciclo di vita precedente perché non è presente alcun elemento DOM HTML fino a quando non viene eseguito il rendering del componente.

StateHasChanged(origine di riferimento) viene chiamato per accodare il rerendering del componente con il nuovo stato ottenuto dalla JS chiamata di interoperabilità (per altre informazioni, vedere rendering dei componenti principali Razor ASP.NET). Non viene creato un ciclo infinito perché StateHasChanged viene chiamato solo quando scrollPosition è null.

PrerenderedInterop.razor:

@page "/prerendered-interop"
@using Microsoft.AspNetCore.Components
@using Microsoft.JSInterop
@inject IJSRuntime JS

<PageTitle>Prerendered Interop</PageTitle>

<h1>Prerendered Interop Example</h1>

<div @ref="divElement" style="margin-top:2000px">
    Set value via JS interop call: <strong>@scrollPosition</strong>
</div>

@code {
    private ElementReference divElement;
    private double? scrollPosition;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender && scrollPosition is null)
        {
            scrollPosition = await JS.InvokeAsync<double>(
                "scrollElementIntoView", divElement);

            StateHasChanged();
        }
    }
}

L'esempio precedente inquina il client con una funzione globale. Per un approccio migliore nelle app di produzione, vedere Isolamento JavaScript nei moduli JavaScript.

Eliminazione dei componenti con IDisposable e IAsyncDisposable

Se un componente implementa IDisposable o IAsyncDisposable, il framework chiama l'eliminazione delle risorse quando il componente viene rimosso dall'interfaccia utente. Non basarsi sulla tempistica esatta di quando questi metodi vengono eseguiti. Ad esempio, IAsyncDisposable può essere attivato prima o dopo che viene chiamato o completato un attesa asincrono Task in OnInitalizedAsync . Inoltre, il codice di eliminazione degli oggetti non deve presupporre che gli oggetti creati durante l'inizializzazione o altri metodi del ciclo di vita esistano.

I componenti non devono implementare IDisposable e IAsyncDisposable contemporaneamente. Se entrambi sono implementati, il framework esegue solo l'overload asincrono.

Il codice dello sviluppatore deve garantire che IAsyncDisposable il completamento delle implementazioni non richiede molto tempo.

Eliminazione dei riferimenti agli oggetti di interoperabilità JavaScript

Esempi in tutti gli articoli di interoperabilità JavaScript (JS) illustrano i modelli di eliminazione di oggetti tipici:

• Quando si chiama JS da .NET, come descritto in Chiamare funzioni JavaScript da metodi .NET in ASP.NET CoreBlazor, eliminare qualsiasi creatoIJSInProcessObjectReference//JSObjectReference IJSObjectReferenceda .NET o da JS per evitare perdite di JS memoria.

• Quando si chiama .NET da JS, come descritto in Chiamare metodi .NET da funzioni JavaScript in ASP.NET CoreBlazor, eliminare un creato DotNetObjectReference da .NET o da JS per evitare perdite di memoria .NET.

JS I riferimenti agli oggetti di interoperabilità vengono implementati come mappa con chiave da un identificatore sul lato della JS chiamata di interoperabilità che crea il riferimento. Quando l'eliminazione di oggetti viene avviata da .NET o JS lato, Blazor rimuove la voce dalla mappa e l'oggetto può essere sottoposto a Garbage Collection purché non sia presente alcun altro riferimento sicuro all'oggetto.

Eliminare sempre gli oggetti creati sul lato .NET per evitare perdite di memoria gestita .NET.

Attività di pulizia DOM durante l'eliminazione dei componenti

Per altre informazioni, vedere ASP.NET Core JavaScript interoperabilità (interoperabilità).For more information, see ASP.NET Core Blazor JavaScript interoperability (JS interop).

Per indicazioni su quando un circuito è disconnesso, vedere ASP.NET'interoperabilità JavaScript core ( interoperabilità).For guidance on JSDisconnectedException when a circuit is disconnected, see ASP.NET Core Blazor JavaScript interoperability (JS interop). Per indicazioni generali sulla gestione degli errori di interoperabilità JavaScript, vedere la sezione Interoperabilità JavaScript in Gestire gli errori nelle app ASP.NET CoreBlazor.

Sincrono IDisposable

Per le attività di eliminazione sincrone, usare IDisposable.Dispose.

Componente seguente:

• Implementa IDisposable con la @implementsRazor direttiva .
• Elimina , objovvero un tipo che implementa IDisposable.
• Viene eseguito un controllo Null perché obj viene creato in un metodo del ciclo di vita (non visualizzato).

@implements IDisposable

...

@code {
    ...

    public void Dispose()
    {
        obj?.Dispose();
    }
}

Se un singolo oggetto richiede l'eliminazione, è possibile usare un'espressione lambda per eliminare l'oggetto quando Dispose viene chiamato . L'esempio seguente viene visualizzato nell'articolo sul rendering dei componenti di Razor base ASP.NET e illustra l'uso di un'espressione lambda per l'eliminazione di un oggetto Timer.

TimerDisposal1.razor:

@page "/timer-disposal-1"
@using System.Timers
@implements IDisposable

<PageTitle>Timer Disposal 1</PageTitle>

<h1>Timer Disposal Example 1</h1>

<p>Current count: @currentCount</p>

@code {
    private int currentCount = 0;
    private Timer timer = new(1000);

    protected override void OnInitialized()
    {
        timer.Elapsed += (sender, eventArgs) => OnTimerCallback();
        timer.Start();
    }

    private void OnTimerCallback()
    {
        _ = InvokeAsync(() =>
        {
            currentCount++;
            StateHasChanged();
        });
    }

    public void Dispose() => timer.Dispose();
}

Nota

Nell'esempio precedente, la chiamata a viene sottoposta a StateHasChanged wrapping da una chiamata a ComponentBase.InvokeAsync perché il callback viene richiamato all'esterno del contesto di Blazorsincronizzazione. Per altre informazioni, vedere Rendering dei componenti di ASP.NET CoreRazor.

Se l'oggetto viene creato in un metodo del ciclo di vita, ad esempio OnInitialized{Async}, verificare la presenza null di prima di chiamare Dispose.

TimerDisposal2.razor:

@page "/timer-disposal-2"
@using System.Timers
@implements IDisposable

<PageTitle>Timer Disposal 2</PageTitle>

<h1>Timer Disposal Example 2</h1>

<p>Current count: @currentCount</p>

@code {
    private int currentCount = 0;
    private Timer? timer;

    protected override void OnInitialized()
    {
        timer = new Timer(1000);
        timer.Elapsed += (sender, eventArgs) => OnTimerCallback();
        timer.Start();
    }

    private void OnTimerCallback()
    {
        _ = InvokeAsync(() =>
        {
            currentCount++;
            StateHasChanged();
        });
    }

    public void Dispose() => timer?.Dispose();
}

Per altre informazioni, vedi:

• Pulizia delle risorse non gestite (documentazione di .NET)
• Operatori condizionali Null ?. e ?[]

Asincrono IAsyncDisposable

Per le attività di eliminazione asincrone, usare IAsyncDisposable.DisposeAsync.

Componente seguente:

• Implementa IAsyncDisposable con la @implementsRazor direttiva .
• Elimina , objovvero un tipo non gestito che implementa IAsyncDisposable.
• Viene eseguito un controllo Null perché obj viene creato in un metodo del ciclo di vita (non visualizzato).

@implements IAsyncDisposable

...

@code {
    ...

    public async ValueTask DisposeAsync()
    {
        if (obj is not null)
        {
            await obj.DisposeAsync();
        }
    }
}

Per altre informazioni, vedi:

• Pulizia delle risorse non gestite (documentazione di .NET)
• Operatori condizionali Null ?. e ?[]

Assegnazione di null a oggetti eliminati

In genere, non è necessario assegnare null agli oggetti eliminati dopo aver chiamato/DisposeDisposeAsync . I rari casi per l'assegnazione null includono quanto segue:

• Se il tipo dell'oggetto non è implementato correttamente e non tollera le chiamate ripetute a Dispose/DisposeAsync, assegnare null dopo l'eliminazione per ignorare normalmente altre chiamate a .Dispose/DisposeAsync
• Se un processo di lunga durata continua a contenere un riferimento a un oggetto eliminato, l'assegnazione null consente al Garbage Collector di liberare l'oggetto nonostante il processo di lunga durata che contiene un riferimento.

Si tratta di scenari insoliti. Per gli oggetti implementati correttamente e si comportano normalmente, non c'è alcun punto da assegnare null agli oggetti eliminati. Nei rari casi in cui è necessario assegnare nullun oggetto , è consigliabile documentare il motivo e cercare una soluzione che impedisca la necessità di assegnare null.

StateHasChanged

Nota

La chiamata StateHasChanged in Dispose e DisposeAsync non è supportata. StateHasChanged potrebbe essere richiamato come parte dell'disinstallazione del renderer, quindi la richiesta di aggiornamenti dell'interfaccia utente a quel punto non è supportata.

Gestori eventi

Annullare sempre la sottoscrizione dei gestori eventi dagli eventi .NET. Gli esempi di modulo seguenti Blazor illustrano come annullare la sottoscrizione di un gestore eventi nel Dispose metodo :

• Campo privato e approccio lambda

  @implements IDisposable
  
  <EditForm ... EditContext="editContext" ...>
      ...
      <button type="submit" disabled="@formInvalid">Submit</button>
  </EditForm>
  
  @code {
      ...
  
      private EventHandler<FieldChangedEventArgs>? fieldChanged;
  
      protected override void OnInitialized()
      {
          editContext = new(model);
  
          fieldChanged = (_, __) =>
          {
              ...
          };
  
          editContext.OnFieldChanged += fieldChanged;
      }
  
      public void Dispose()
      {
          editContext.OnFieldChanged -= fieldChanged;
      }
  }
  

• Approccio al metodo privato

  @implements IDisposable
  
  <EditForm ... EditContext="editContext" ...>
      ...
      <button type="submit" disabled="@formInvalid">Submit</button>
  </EditForm>
  
  @code {
      ...
  
      protected override void OnInitialized()
      {
          editContext = new(model);
          editContext.OnFieldChanged += HandleFieldChanged;
      }
  
      private void HandleFieldChanged(object sender, FieldChangedEventArgs e)
      {
          ...
      }
  
      public void Dispose()
      {
          editContext.OnFieldChanged -= HandleFieldChanged;
      }
  }
  

Per altre informazioni, vedere la sezione Eliminazione dei componenti con IDisposable e IAsyncDisposable .

Per altre informazioni sul EditForm componente e sui moduli, vedere ASP.NET Cenni preliminari sui moduli di base Blazor e gli altri articoli relativi ai moduli nel nodo Moduli.

Funzioni, metodi ed espressioni anonime

Quando vengono usate funzioni, metodi o espressioni anonime, non è necessario implementare e annullare IDisposable la sottoscrizione dei delegati. Tuttavia, la mancata sottoscrizione di un delegato è un problema quando l'oggetto che espone l'evento dura la durata del componente che registra il delegato. In questo caso, si verifica una perdita di memoria perché il delegato registrato mantiene attivo l'oggetto originale. Pertanto, usare gli approcci seguenti solo quando si sa che il delegato dell'evento elimina rapidamente. In caso di dubbi sulla durata degli oggetti che richiedono l'eliminazione, sottoscrivere un metodo delegato ed eliminare correttamente il delegato come illustrato negli esempi precedenti.

• Approccio anonimo al metodo lambda (eliminazione esplicita non richiesta):

  private void HandleFieldChanged(object sender, FieldChangedEventArgs e)
  {
      formInvalid = !editContext.Validate();
      StateHasChanged();
  }
  
  protected override void OnInitialized()
  {
      editContext = new(starship);
      editContext.OnFieldChanged += (s, e) => HandleFieldChanged((editContext)s, e);
  }
  

• Approccio anonimo per l'espressione lambda (eliminazione esplicita non necessaria):

  private ValidationMessageStore? messageStore;
  
  [CascadingParameter]
  private EditContext? CurrentEditContext { get; set; }
  
  protected override void OnInitialized()
  {
      ...
  
      messageStore = new(CurrentEditContext);
  
      CurrentEditContext.OnValidationRequested += (s, e) => messageStore.Clear();
      CurrentEditContext.OnFieldChanged += (s, e) => 
          messageStore.Clear(e.FieldIdentifier);
  }
  

  L'esempio completo del codice precedente con espressioni lambda anonime viene visualizzato nell'articolo ASP.NET convalida dei moduli coreBlazor.

Per altre informazioni, vedere Pulizia delle risorse non gestite e degli argomenti che seguono l'implementazione dei Dispose metodi e DisposeAsync .

Eliminazione durante JS l'interoperabilità

Trap JSDisconnectedException nei casi potenziali in cui la perdita del SignalR Blazorcircuito impedisce JS chiamate di interoperabilità e genera un'eccezione non gestita.

Per ulteriori informazioni, vedi le seguenti risorse:

• Isolamento JavaScript nei moduli JavaScript
• Chiamate di interoperabilità JavaScript senza circuito

Lavoro in background annullabile

I componenti spesso eseguono operazioni in background a esecuzione prolungata, ad esempio l'esecuzione di chiamate di rete (HttpClient) e l'interazione con i database. È consigliabile arrestare il lavoro in background per risparmiare risorse di sistema in diverse situazioni. Ad esempio, le operazioni asincrone in background non vengono interrotte automaticamente quando un utente si allontana da un componente.

Altri motivi per cui gli elementi di lavoro in background potrebbero richiedere l'annullamento includono:

• Un'attività in background in esecuzione è stata avviata con dati di input difettosi o parametri di elaborazione.
• Il set corrente di elementi di lavoro in background in esecuzione deve essere sostituito con un nuovo set di elementi di lavoro.
• La priorità delle attività attualmente in esecuzione deve essere modificata.
• L'app deve essere arrestata per la ridistribuzione del server.
• Le risorse del server diventano limitate e richiedono la riprogrammazione degli elementi di lavoro in background.

Per implementare un modello di lavoro in background annullabile in un componente:

• Usare e CancellationTokenSource CancellationToken.
• Per eliminare il componente e in qualsiasi momento è necessario annullare manualmente il token, chiamare CancellationTokenSource.Cancel per segnalare che il lavoro in background deve essere annullato.
• Al termine della chiamata asincrona, chiamare ThrowIfCancellationRequested sul token.

Nell'esempio seguente :

• await Task.Delay(5000, cts.Token); rappresenta il lavoro in background asincrono a esecuzione prolungata.
• BackgroundResourceMethod rappresenta un metodo in background con esecuzione prolungata che non deve iniziare se viene Resource eliminato prima che venga chiamato il metodo .

BackgroundWork.razor:

@page "/background-work"
@implements IDisposable
@inject ILogger<BackgroundWork> Logger

<PageTitle>Background Work</PageTitle>

<h1>Background Work Example</h1>

<p>
    <button @onclick="LongRunningWork">Trigger long running work</button>
    <button @onclick="Dispose">Trigger Disposal</button>
</p>
<p>Study logged messages in the console.</p>
<p>
    If you trigger disposal within 10 seconds of page load, the 
    <code>BackgroundResourceMethod</code> isn't executed.
</p>
<p>
    If disposal occurs after <code>BackgroundResourceMethod</code> is called but
    before action is taken on the resource, an <code>ObjectDisposedException</code>
    is thrown by <code>BackgroundResourceMethod</code>, and the resource isn't
    processed.
</p>

@code {
    private Resource resource = new();
    private CancellationTokenSource cts = new();
    private IList<string> messages = [];

    protected async Task LongRunningWork()
    {
        Logger.LogInformation("Long running work started");

        await Task.Delay(10000, cts.Token);

        cts.Token.ThrowIfCancellationRequested();
        resource.BackgroundResourceMethod(Logger);
    }

    public void Dispose()
    {
        Logger.LogInformation("Executing Dispose");

        if (!cts.IsCancellationRequested)
        {
            cts.Cancel();
        }
        
        cts?.Dispose();
        resource?.Dispose();
    }

    private class Resource : IDisposable
    {
        private bool disposed;

        public void BackgroundResourceMethod(ILogger<BackgroundWork> logger)
        {
            logger.LogInformation("BackgroundResourceMethod: Start method");

            if (disposed)
            {
                logger.LogInformation("BackgroundResourceMethod: Disposed");
                throw new ObjectDisposedException(nameof(Resource));
            }

            // Take action on the Resource

            logger.LogInformation("BackgroundResourceMethod: Action on Resource");
        }

        public void Dispose() => disposed = true;
    }
}

Blazor Server eventi di riconnessione

Gli eventi del ciclo di vita dei componenti trattati in questo articolo operano separatamente dai gestori eventi di riconnessione lato server. Quando la SignalR connessione al client viene persa, vengono interrotti solo gli aggiornamenti dell'interfaccia utente. Gli aggiornamenti dell'interfaccia utente vengono ripresi quando viene ristabilita la connessione. Per altre informazioni sugli eventi e sulla configurazione del gestore del circuito, vedere ASP.NET Linee guida di baseBlazorSignalR.

Risorse aggiuntive

Gestire le eccezioni rilevate al di fuori del ciclo di vita di un Razor componente