Component lifecycles

Blazor components have a number of virtual methods we can override to affect the behaviour of our application. These methods are executed at different times during a component’s lifetime. The following diagram outlines the flow of these lifecycle methods.


After the component is created, this is the first method to be executed. The parameters that are to be passed into the component are specified in a ParameterView. This is a good point at which to make asynchronous calls out to a server etc based on the state being passed into the component, before any of the component’s [Parameter] properties have been assigned any state.

It is also the correct place to assign default parameter values. See Optional route parameters for a full explanation.

OnInitialized / OnInitializedAsync

Once the state from the ParameterCollection has been assigned to the component’s [Parameter] properties, these methods are executed. This is useful in the same way as SetParametersAsync, except it is possible to use the component’s state.

Note: When the component is a @page, and our Blazor app navigates to a new URL that renders the same page Blazor does not execute OnInitialized again. See Optional route parameters for more information.

OnParametersSet / OnParametersSetAsync

These are the first pair of methods in a component’s lifecycle that are potentially called repeatedly. If none of the component’s [Parameter] properties change then the component will simply idle until it is finally destroyed. However, if any of the parameters in its parent’s HTML markup are altered then these methods will fire after the component’s state has been updated. This will then cause Blazor to recalculate the component’s RenderTree, and then execute the OnAfterRender and OnAfterRenderAsync methods.

OnAfterRender / OnAfterRenderAsync

These last two methods are executed every time Blazor has re-generated the component’s RenderTree. This can be as a result of the component’s [Parameter] properties being changed in its parent’s HTML mark-up, as a consequence of the user interacting with the component (e.g. a mouse-click), or if the component executes its StateHasChanged method to invoke a re-render.


This method doesn’t qualify as a lifecycle method, but it does trigger another method that is part of the lifecycle of a component. By default, Blazor will check if its state has changed after certain interactions (such as a button click). Sometimes Blazor cannot be aware of a change to state due to how it was triggered, for example when triggered by a Timer.

In these circumstances we are expected to call StateHasChanged, which will queue up a render request with Blazor for a re-render, and this will trigger OnAfterRender and OnAfterRenderAsync.


Although this isn’t strictly one of the ComponentBase’s lifecycle methods, if a component implements IDisposable then Blazor will execute Dispose once the component is removed from its parent’s render tree. To implement IDisposable we need to add @implements IDisposable to our razor file.

@implements IDisposable
<h1>This is MyComponent</h1>

@code {
	void IDisposable.Dispose()
		// Code here