Informazioni sul ciclo di vita dei componenti Blazor
I componenti Blazor hanno un ciclo di vita ben definito che inizia quando vengono creati per la prima volta e termina quando vengono eliminati definitivamente. Il ciclo di vita del componente è regolato da un set di eventi che si verificano in risposta a trigger specifici. Tali trigger includono l'inizializzazione del componente, l'interazione degli utenti con il componente o la chiusura della pagina in cui si trova il componente.
In questa unità verranno illustrati gli eventi che si verificano durante il ciclo di vita di un componente Blazor. Verrà illustrato come gestire questi eventi per ottimizzare il lavoro eseguito e aumentare la velocità di risposta di una pagina Blazor.
Ciclo di vita dei componenti Blazor
I componenti Blazor rappresentano le viste nelle app Blazor, che definiscono il layout e la logica dell'interfaccia utente. I componenti generano markup HTML quando l'app viene eseguita. Gli eventi di interazione utente possono attivare codice personalizzato e i componenti possono essere aggiornati per ripristinare la visualizzazione. Alla chiusura della pagina, Blazor rimuove il componente e pulisce le risorse. Le nuove istanze vengono create quando l'utente torna alla pagina.
Il diagramma seguente illustra gli eventi che si verificano durante la durata di un componente e i metodi che è possibile usare per gestire questi eventi. Ad eccezione di SetParametersAsync, Blazor fornisce versioni sincrone e asincrone di ogni metodo.
Tutti i componenti Blazor derivano dalla classe ComponentBase o IComponent che definisce i metodi visualizzati e fornisce il comportamento predefinito. Per gestire un evento, eseguire l'override del metodo corrispondente.
Anche se il diagramma suggerisce un singolo flusso in thread tra i metodi del ciclo di vita, le versioni asincrone di questi metodi consentono a un'app Blazor di accelerare il processo di rendering. Ad esempio, quando si verifica il primo await in SetParametersAsync, il componente Blazor esegue i metodi OnInitialized e OnInitializedAsync. Al termine dell'istruzione prevista, il thread di esecuzione in SetParametersAsync riprende.
La stessa logica si applica a tutta la serie di metodi del ciclo di vita. Inoltre, ogni operazione await che si verifica durante OnInitializedAsync e OnParametersSetAsync indica che lo stato del componente è stato modificato e può attivare un rendering immediato della pagina. Il rendering della pagina potrebbe essere eseguito più volte prima del completamento dell'inizializzazione.
Informazioni sui metodi relativi al ciclo di vita
Ogni metodo nel ciclo di vita dei componenti ha uno scopo specifico. È possibile eseguire l’override di questi metodi per implementare logiche personalizzate per il componente. La tabella seguente elenca i metodi del ciclo di vita nell'ordine in cui si verificano e ne descrive lo scopo.
| Ordine | Metodo del ciclo di vita | Descrizione |
|---|---|---|
| 1 | Componente creato | Viene creata un'istanza del componente. |
| 2 | SetParametersAsync | Imposta i parametri dall'elemento padre del componente nell'albero di rendering. |
| 3 | OnInitialized / OnInitializedAsync | Si verifica quando il componente è pronto per l'avvio. |
| 4 | OnParametersSet / OnParametersSetAsync | Si verifica quando sono stati assegnati parametri e proprietà al componente. |
| 5 | OnAfterRender / OnAfterRenderAsync | Si verifica dopo il rendering del componente. |
| 6 | Dispose / DisposeAsync |
Se il componente implementa IDisposable o IAsyncDisposable, viene eseguito il metodo appropriato quando il componente viene distrutto. |
Metodo SetParametersAsync
Quando un utente visita una pagina che contiene un componente Blazor, il runtime di Blazor crea una nuova istanza del componente ed esegue il costruttore predefinito. Dopo aver costruito il componente, il runtime di Blazor chiama il metodo SetParametersAsync.
Se il componente definisce parametri, il runtime di Blazor inserisce i valori per questi parametri dall'ambiente chiamante nel componente. Questi parametri sono contenuti in un oggetto ParameterView e sono resi accessibili al metodo SetParametersAsync. È possibile chiamare il metodo base.SetParametersAsync per popolare le proprietà Parameter del componente con questi valori.
In alternativa, se è necessario gestire i parametri in modo diverso, è possibile farlo con questo metodo. Ad esempio, potrebbe essere necessario convalidare tutti i parametri passati al componente prima di usarli.
Nota
Il metodo SetParametersAsync viene sempre eseguito durante la creazione di un componente, indipendentemente dal fatto che esso non disponga di parametri.
Metodi OnInitialized e OnInitializedAsync
È possibile eseguire l'override dei metodi OnInitialized e OnInitializedAsync per includere funzionalità personalizzate. Questi metodi vengono eseguiti dopo che il metodo SetParametersAsync popola le proprietà basate su parametri del componente, che sono attribuiti con ParameterAttribute o CascadingParameterAttribute. Eseguire la logica di inizializzazione in questi metodi.
Se la proprietà render-mode dell'applicazione è impostata su Server, i metodi OnInitialized e OnInitializedAsync vengono eseguiti una sola volta per un'istanza del componente. Se un elemento padre del componente modifica i parametri del componente, il metodo SetParametersAsync viene eseguito di nuovo, ma questi metodi non verranno eseguiti. Se è necessario reinizializzare un componente quando si modificano i parametri, usare il metodo SetParametersAsync. Se si vuole eseguire l'inizializzazione una sola volta, usare questi metodi.
Se la proprietà render-mode è impostata su ServerPrerendered, i metodi OnInitialized e OnInitializedAsync vengono eseguiti due volte: una volta durante la fase di prerendering che genera l'output della pagina statica e un'altra volta quando il server stabilisce una connessione SignalR con il browser. In questi metodi è possibile eseguire attività di inizializzazione più complesse, ad esempio il recupero di dati da un servizio Web usato per impostare lo stato del componente Blazor. In questo caso, è consigliabile memorizzare nella cache le informazioni sullo stato durante la prima esecuzione e riutilizzare lo stato precedentemente salvato durante la seconda esecuzione.
Tutte le dipendenze usate dal componente Blazor vengono inserite dopo la creazione dell'istanza ma prima dell'esecuzione dei metodi OnInitialized o OnInitializedAsync. È possibile usare gli oggetti inseriti da queste dipendenze nei metodi OnInitialized o OnInitializedAsync, ma non prima.
Importante
I componenti Blazor non supportano l'inserimento delle dipendenze dei costruttori. Usare invece la direttiva @inject nel markup del componente o InjectAttribute nella dichiarazione di proprietà.
Durante la fase di prerendering, il codice in un componente Blazor Server non può eseguire azioni che richiedono una connessione al browser, ad esempio la chiamata di codice JavaScript. È consigliabile inserire la logica che dipende da una connessione con il browser nei metodi OnAfterRender o OnAfterRenderAsync.
Metodi OnParametersSet e OnParametersSetAsync
I metodi OnParametersSet e OnParametersSetAsync vengono eseguiti dopo il primo rendering del componente OnInitialized o OnInitializedAsync dopo il rendering successivo del metodo SetParametersAsync. Analogamente a SetParametersAsync, questi metodi vengono sempre chiamati, anche se il componente non dispone di parametri.
Usare uno dei metodi per completare le attività di inizializzazione che dipendono dai valori dei parametri del componente, ad esempio il calcolo dei valori per le proprietà calcolate. Non eseguire operazioni che richiedono un’esecuzione prolungata, come quelle in un costruttore. I costruttori sono sincroni e l'attesa del completamento delle operazioni a esecuzione prolungata influisce sulla velocità di risposta della pagina che contiene il componente.
Metodi OnAfterRender e OnAfterRenderAsync
I metodi OnAfterRender e OnAfterRenderAsync vengono eseguiti ogni volta che il runtime di Blazor deve aggiornare la visualizzazione rappresentata dal componente nell'interfaccia utente. Questo stato si verifica automaticamente quando:
- Lo stato del componente cambia, ad esempio quando vengono eseguiti i metodi
OnInitializedoOnInitializedAsyncoppure quando vengono eseguiti i metodiOnParametersSeteOnParametersSetAsync. - Viene attivato un evento dell'interfaccia utente.
- Il codice dell'applicazione chiama il metodo
StateHasChangeddel componente.
Quando viene chiamato StateHasChanged, da un evento esterno o da un trigger dell'interfaccia utente, il componente esegue di nuovo il rendering in modo condizionale. Nell'elenco seguente viene dettagliato l'ordine delle chiamate al metodo, incluso StateHasChanged e successivi:
- StateHasChanged: il componente è contrassegnato come necessario per eseguire il ripristino.
- ShouldRender: restituisce un flag che indica se il rendering del componente deve essere eseguito.
- BuildRenderTree: esegue il rendering del componente.
Il metodo StateHasChanged chiama il metodo ShouldRender del componente. Lo scopo di questo metodo consiste nel determinare se la modifica dello stato richiede un nuovo rendering della visualizzazione da parte del componente. Per impostazione predefinita, tutte le modifiche dello stato attivano un'operazione di rendering, ma è possibile sostituire il metodo ShouldRender e definire la logica decisionale. Il metodo ShouldRender restituisce true se è necessario eseguire il rendering della visualizzazione o, in caso contrario, false.
Se il componente richiede il rendering, è possibile usare il metodo BuildRenderTree per generare un modello che può essere usato per aggiornare la versione del DOM usata dal browser per visualizzare l'interfaccia utente. È possibile usare l'implementazione predefinita del metodo fornito dalla classe ComponentBase, oppure eseguire l’override con la logica personalizzata in caso di requisiti specifici.
Viene quindi eseguito il rendering della visualizzazione del componente e viene aggiornata l'interfaccia utente. Infine, il componente esegue i metodi OnAfterRender e OnAfterRenderAsync. A questo punto, l'interfaccia utente è completamente funzionante ed è possibile interagire con JavaScript e tutti gli elementi nel DOM. Usare questi metodi per eseguire altre procedure che richiedono l'accesso al contenuto sottoposto a rendering completo, ad esempio chiamare il codice JavaScript dall'interoperabilità JS.
I metodi OnAfterRender e OnAfterRenderAsync accettano un parametro booleano denominato firstRender. Questo parametro è true la prima volta che vengono eseguiti i metodi, ma è false successivamente. È possibile valutare questo parametro per eseguire operazioni singole che potrebbero essere inutili e che richiedono troppo risorse se vengono ripetute ogni volta che viene eseguito il rendering del componente.
Nota
Non confondere il prerendering con il primo rendering per un componente Blazor. Il prerendering si verifica prima che venga stabilita una connessione SignalR con il browser e genera una versione statica di una pagina. Il primo rendering si verifica quando la connessione con il browser è completamente attiva e tutte le funzionalità sono disponibili.
Metodi Dispose e DisposeAsync
Come tutte le classi .NET, un componente Blazor può usare risorse gestite e non gestite. Il runtime recupera automaticamente le risorse gestite. Tuttavia, è necessario implementare le interfacce IDisposable o IAsyncDisposable e fornire un metodo Dispose o DisposeAsync per rilasciare le risorse non gestite. In questo modo si riducono le probabilità di perdite di memoria nel server.
Gestire le eccezioni nei metodi del ciclo di vita
Se un metodo del ciclo di vita per un componente Blazor ha esito negativo, la connessione SignalR al browser viene chiusa che a sua volta causa l'arresto del funzionamento dell'app Blazor. Per evitare questo esito, assicurarsi di essere pronti a gestire le eccezioni come parte della logica per i metodi del ciclo di vita. Per altre informazioni, vedere Gestire gli errori nelle app ASP.NET Core Blazor.