Descripción del ciclo de vida de un componente de Blazor
Los componentes de Blazor tienen un ciclo de vida bien definido que comienza cuando se crean por primera vez y termina cuando se destruyen. El ciclo de vida del componente se rige por un conjunto de eventos que ocurren en respuesta a desencadenadores específicos. Estos desencadenadores incluyen el componente que se inicializa, los usuarios que interactúan con el componente o la página donde reside el componente que se cierra.
En esta unidad, conocerá los eventos que se producen durante el ciclo de vida de un componente de Blazor. Verá cómo controlar estos eventos para optimizar el trabajo realizado y aumentar la capacidad de respuesta de una página de Blazor.
Ciclo de vida de un componente de Blazor
Los componentes de Blazor representan las vistas en las aplicaciones Blazor, que definen el diseño y la lógica de la UI. Los componentes generan marcado HTML cuando se ejecuta la aplicación. Los eventos de interacción del usuario pueden desencadenar código personalizado y los componentes se pueden actualizar para volver a representar la pantalla. Al cerrar la página, Blazor quita el componente y limpia todos los recursos. Las nuevas instancias se crean cuando el usuario vuelve a la página.
En el diagrama siguiente se muestran los eventos que tienen lugar durante la vigencia de un componente y los métodos que puede usar para controlar estos eventos. Blazor ofrece versiones sincrónicas y asincrónicas de cada método excepto para SetParametersAsync.
Todos los componentes de Blazor descienden de la clase ComponentBase o IComponent que define los métodos mostrados y establece el comportamiento predeterminado. Para controlar un evento, invalide el método correspondiente.
Aunque el diagrama indica que hay un único flujo de subprocesos entre los métodos del ciclo de vida, las versiones asincrónicas de estos métodos permiten que una aplicación de Blazor acelere el proceso de representación. Por ejemplo, cuando se produce el primer await en SetParametersAsync, el componente de Blazor ejecuta los métodos OnInitialized y OnInitializedAsync. Cuando la instrucción esperada se completa, se reanuda el subproceso de ejecución en SetParametersAsync.
La misma lógica se aplica a lo largo de toda la serie de métodos del ciclo de vida. Además, cada operación await que se produce durante OnInitializedAsync y OnParametersSetAsync indica que el estado del componente ha cambiado, y puede desencadenar una representación inmediata de la página. Es posible que la página se represente varias veces antes de que la inicialización se complete totalmente.
Descripción de los métodos del ciclo de vida
Cada método de ciclo de vida de componente tiene una finalidad específica y puede invalidar los métodos para agregar lógica personalizada al componente. En la tabla siguiente se enumeran los métodos de ciclo de vida en el orden en que se producen y se describe su finalidad.
| Pedido | Método de ciclo de vida | Descripción |
|---|---|---|
| 1 | Componente creado | Se crea una instancia del componente. |
| 2 | SetParametersAsync | Establece los parámetros del elemento primario del componente en el árbol de representación. |
| 3 | OnInitialized / OnInitializedAsync | Se produce cuando el componente está listo para iniciarse. |
| 4 | OnParametersSet / OnParametersSetAsync | Se produce cuando el componente ha recibido parámetros y se han asignado propiedades. |
| 5 | OnAfterRender / OnAfterRenderAsync | Se produce después de que el componente se haya representado. |
| 6 | Dispose / DisposeAsync |
Si el componente implementa IDisposable o IAsyncDisposable, se produce el desechable adecuado como parte de la destrucción del componente. |
Método SetParametersAsync
Cuando un usuario visita una página que contiene un componente de Blazor, el entorno de ejecución de Blazor crea una nueva instancia del componente y ejecuta el constructor predeterminado. Una vez que se ha construido el componente, el runtime de Blazor llama al método SetParametersAsync.
Si el componente define algún parámetro, el runtime de Blazor inserta los valores de estos parámetros desde el entorno de llamada en el componente. Estos parámetros están contenidos en un objeto ParameterView y son accesibles para el método SetParametersAsync. Se llama al método base.SetParametersAsync para rellenar las propiedades de Parameter del componente con estos valores.
Como alternativa, si tiene que controlar los parámetros de una manera diferente, este método es el lugar para hacerlo. Por ejemplo, es posible que tenga que validar los parámetros que se pasen al componente antes de usarlos.
Nota
El método SetParametersAsync siempre se ejecuta cuando se crea un componente, incluso si el componente no tiene ningún parámetro.
Métodos OnInitialized y OnInitializedAsync
Puede anular los métodos OnInitialized y OnInitializedAsync se pueden invalidar para incluir la funcionalidad personalizada. Estos métodos se ejecutan después de que el método SetParametersAsync rellene las propiedades basadas en parámetros del componente, que se atribuyen a ParameterAttribute o CascadingParameterAttribute. La lógica de inicialización se ejecuta en estos métodos.
Si la propiedad render-mode de la aplicación se establece en Server y los métodos OnInitialized y OnInitializedAsync solo se ejecutan una vez para una instancia de componente. Si un elemento primario del componente modifica los parámetros del componente, el método SetParametersAsync vuelve a ejecutarse de nuevo, pero estos métodos no. Si tiene que reinicializar un componente cuando los parámetros cambian, use el método SetParametersAsync. Si quiere realizar la inicialización una vez, use estos métodos.
Si la propiedad render-mode se establece en ServerPrerendered, los métodos OnInitialized y OnInitializedAsync se ejecutan dos veces; una vez durante la fase de representación previa que genera la salida de la página estática y otra vez cuando el servidor establece una conexión SignalR con el explorador. Es posible que realice tareas de inicialización costosas en estos métodos, como recuperar datos de un servicio web que use para establecer el estado del componente de Blazor. En este caso, almacene en caché la información de estado durante la primera ejecución y reutilice el estado guardado durante la segunda ejecución.
Las dependencias que el componente de Blazor usa se insertan cuando se ha creado la instancia, pero antes de que se ejecuten los métodos OnInitialized u OnInitializedAsync. Puede usar los objetos que insertan estas dependencias en los métodos OnInitialized u OnInitializedAsync, pero no antes.
Importante
Los componentes de Blazor no admiten la inserción de dependencias de constructor. En su lugar, use la directiva @inject en el marcado de componente o en InjectAttribute en la declaración de propiedad.
Durante la fase de representación previa, el código de un componente de Blazor Server no puede realizar acciones que requieran una conexión al explorador, como llamar a código de JavaScript. Debe colocar la lógica que depende de una conexión con el explorador en los métodos OnAfterRender o OnAfterRenderAsync.
Métodos OnParametersSet y OnParametersSetAsync
Los métodos OnParametersSet y OnParametersSetAsync se ejecutan después de los métodos OnInitialized u OnInitializedAsync la primera vez que se representa el componente, o después del método SetParametersAsync en la representación posterior. Al igual que SetParametersAsync, siempre se llama a estos métodos, incluso si el componente no tiene parámetros.
Use uno de los métodos para completar las tareas de inicialización que dependen de los valores de los parámetros del componente, como calcular los valores de las propiedades calculadas. No realice operaciones de larga duración como estas en un constructor. Los constructores son sincrónicos y esperar a que se completen las operaciones de larga duración afecta a la capacidad de respuesta de la página que contiene el componente.
Métodos OnAfterRender y OnAfterRenderAsync
Los métodos OnAfterRender y OnAfterRenderAsync se ejecutan cada vez que el runtime de Blazor tiene que actualizar la vista representada por el componente en la interfaz de usuario. Este estado se produce automáticamente cuando:
- El estado del componente cambia, por ejemplo, cuando se ejecutan los métodos
OnInitializeduOnInitializedAsynco los métodosOnParametersSetyOnParametersSetAsyncse ejecutan. - Se desencadena un evento de UI.
- El código de la aplicación llama al método
StateHasChangeddel componente.
Cuando se llama a StateHasChanged, ya sea desde un evento externo o un desencadenador de UI, el componente vuelve a representarse condicionalmente. En la lista siguiente se detalla el orden de las invocaciones de método, incluida StateHasChanged:
- StateHasChanged: el componente se marca como necesario para volver a representar.
- ShouldRender: devuelve una marca que indica si el componente debe representarse.
- BuildRenderTree: representa el componente.
El método StateHasChanged llama al método ShouldRender del componente. La finalidad de este método es determinar si el cambio de estado requiere que el componente vuelva a representar la vista. De manera predeterminada, todos los cambios de estado desencadenan una operación de representación, pero se puede invalidar el método ShouldRender y definir su lógica de toma de decisiones. El método ShouldRender devuelve true si la vista se debe representarse de nuevo o, de lo contrario, false.
Si es necesario representar el componente, puede usar el método BuildRenderTree para generar un modelo que pueda actualizar la versión de DOM que usa el explorador para mostrar la interfaz de usuario. Puede usar la implementación de método predeterminada que la clase ComponentBase proporciona, o bien puede invalidarla por su lógica personalizada si tiene requisitos específicos.
A continuación, se representa la vista del componente y se actualiza la UI. Por último, el componente ejecuta los métodos OnAfterRender y OnAfterRenderAsync. En este momento, la UI es totalmente funcional, y usted puede interactuar con JavaScript y cualquier elemento de DOM. Use estos métodos para realizar otros pasos que requieran acceso al contenido totalmente representado, como llamar al código de JavaScript desde la interoperabilidad de JS.
Los métodos OnAfterRender y OnAfterRenderAsync toman un parámetro booleano denominado firstRender. Este parámetro es true la primera vez que se ejecutan los métodos, pero false con posterioridad. Puede evaluar este parámetro para realizar operaciones únicas que podrían generar desperdicios y hacer un uso intensivo de recursos si se repiten cada vez que el componente se representa.
Nota:
No confunda la representación previa con la primera representación de un componente de Blazor. La representación previa se produce antes de establecer una conexión de SignalR con el explorador y genera una versión estática de una página. La primera representación se produce cuando la conexión con el explorador está totalmente activa y toda la funcionalidad está disponible.
Métodos Dispose y DisposeAsync
Al igual que cualquier clase de .NET, un componente de Blazor puede usar recursos administrados y no administrados. El runtime reclama automáticamente los recursos administrados. Sin embargo, se deben implementar las interfaces IDisposable o IAsyncDisposable y proporcionar un método Dispose o DisposeAsync para liberar los recursos no administrados. Esta práctica reduce las posibilidades de fugas de memoria en el servidor.
Control de excepciones en los métodos de ciclo de vida
Si se produce un error en un método del ciclo de vida para un componente de Blazor, se cierra la conexión de SignalR al explorador, lo que, a su vez, hace que la aplicación de Blazor deje de funcionar. Para evitar este resultado, asegúrese de que está preparado para controlar las excepciones como parte de la lógica de los métodos del ciclo de vida. Para más información, consulte Control de errores en aplicaciones Blazor de ASP.NET Core.