жизненный цикл blazor приложения
The Blazor framework provides synchronous and asynchronous versions of application lifecycle methods and can be used to perform additional initialization and checks on the component. In this blog, we are going to look into these Blazor lifecycle methods and understand how and when they are called.
Blazor Application Lifecycle Methods
The Blazor application lifecycle methods provide a way to execute additional functionality or operations on a Razor component while it is being initialized and being rendered. The following are the lifecycle methods that are executed during the initializing and rendering of the component.
As we can see in the above method list every method has its asynchronous version. This asynchronous version is executed only after the synchronous version has completed its execution.
Blazor Lifecycle Methods – Flow and Explanation
Let us discuss each of the method in details below:
SetParametersAsync
SetParametersAsync is the first method that is executed when the component is created. This method sets the parameters that are provided by the parent of the component in the rendering tree. The method provides the parameter called ParameterView which contains all the values for every property with the [Parameter] or [CascadingParamter] attribute.
OnInitialized and OnInitializedAsync
The OnInitialized and OnInitializedAsync methods as its name suggests is invoked when the component is being initialized. These methods are invoked when the parent component has passed the initial parameter to the initializing component.
These methods are the ideal place to call any data services required by the component. And if the requirement is to refresh the UI after the data is loaded, calling the asynchronous version is the place to do so.
OnParametersSet and OnParametersSetAsync
The OnParametersSet and OnParametersSetAsync methods are called when the component has received parameters from its parent component and these values are assigned to its properties. These methods are invoked whenever the parent component re-renders or new or parameters are updated by its parent component which in turn executes the OnAfterRender and OnAfterRenderAsync methods.
OnAfterRender and OnAfterRenderAsync
The OnAfterRender and OnAfterRenderAsync methods are called after the component has finished rendering. At this point, all the elements and the component references are populated. The methods can be used to perform additional initialization of the component, such as event attaching an event listener or initializing the JavaScript libraries which require the DOM elements to be present in order to work.
These methods have “firstRender” parameter that is set to true only for the first time when the component instance is rendered and can be used to make sure that the initialization of the component is done only once.
ShouldRender
The ShouldRender method is invoked right before the component is re-rendered and can be used to stop the current and future rendering of the component. If the method returns true the UI is refreshed else the refreshing is suppressed.
StateHasChanged
This is a special method that does not belong to the Blazor lifecycle methods group but is used to notify that the state of the component has changed and asking the framework to refresh the UI.
Code to display Blazor Lifecycle Methods
The sample code to display the invocation of the method.
Output of the code
This concludes the post about the Blazor Lifecycle Methods and I hope you found this post helpful. Thanks for visiting, Cheers.
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.
Component lifecycle diagram
SetParametersAsync
This method is executed whenever the parent renders.
The component’s [Parameter] properties are assigned their values when you call base.SetParametersAsync(parameters) inside your override.
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.
* This method is only executed once when the component is first created. If the parent changes the component’s parameters at a later time, this method is skipped.
OnParametersSet / OnParametersSetAsync
This method will be executed immediately after OnInitializedAsync if this is a new instance of a component. If it is an existing component that is being re-rendered because its parent is re-rendering then the OnInitialized* methods will not be executed, and this method will be executed immediately after SetParametersAsync instead.
StateHasChanged
This method flags the component to be rendered.
A component will call this method whenever it wants to inform Blazor that changes have occurred that would result in the rendered output being different. For example, in a Clock component we might set off a recurring 1 second timer than executes StateHasChanged in order to re-render with the correct time.
Another use is to instruct Blazor to perform re-renders part way through an asynchronous method.
The call to StateHasChanged will be honoured when an await occurs (line 6) or when the method completes (line 10).
ShouldRender
Instructing Blazor not to go through the BuildRenderTree process can save processing time and improve the user’s experience when we know that our state is either unaltered since the last render, or only altered in a way that would cause identical output to be rendered.
* This method is not executed the first time the component is rendered.
BuildRenderTree
This method renders the component’s content to an in-memory representation (RenderTree) of what should be rendered to the user.
Note: For rendering efficiency, whenever possible always use the @key directive when rendering mark-up within any kind of loop.
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 parent re-rendering, the user interacting with the component (e.g. a mouse-click), or if the component executes its StateHasChanged method to invoke a re-render.
It is not until after the OnAfterRender methods have executed that it is safe to use any references to components set via the @ref directive.
And it is not until after the OnAfterRender methods have been executed with firstRender set to true that it is safe to use any references to HTML elements set via the @ref directive.
Dispose
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.
Awaiting within Async lifecycle methods
It is important to note that instead of waiting for long-running asynchronous methods to complete before being able to render a component, Blazor will trigger a render as soon as it possibly can.
This enables the component to render mark-up for the user to see whilst it performs background tasks such as retrieving data from a server.
Individual method await behaviours
SetParametersAsync
Note: The base.SetParametersAsync method must be executed before any await instructions in the method, otherwise an InvalidOperationException will be thrown.
OnInitializedAsync
OnParametersSetAsync
OnAfterRenderAsync
All other async methods can suspend the lifecycle process until execution exits the method, and the first await will cause a render via BuildRenderTree to prevent the user from having to wait to see updates.
Component lifecycle with asynchronous awaits
Asynchronous methods and multiple awaits
If we want to render at additional points then we must call StateHasChanged just before all additional await statements.
For more information about how to work safely with different threads running on the same component, see the section on Multi-threaded rendering.
Отрисовка компонента Blazor ASP.NET Core
Компоненты должны отрисовываться при первом добавлении в иерархию компонентов их родительским компонентом. Это единственный случай, когда отрисовка компонента обязательна. Компоненты могут отрисовываться в любых других случаях в соответствии с их собственной логикой и соглашениями.
Соглашения об отрисовке ComponentBase
По умолчанию компоненты Razor наследуются от базового класса ComponentBase, который содержит логику, вызывающую повторную отрисовку в следующие моменты времени:
Компоненты, унаследованные от ComponentBase пропускают повторную отрисовку при обновлении параметров в том случае, если выполняется одно из следующих условий:
Управление потоком отрисовки
В большинстве случаев соглашения для ComponentBase определяют корректное подмножество повторных отрисовок компонента после наступления события. Разработчикам как правило не требуется предоставлять вручную логику, указывающую платформе, какие компоненты и когда следует повторно отрисовывать. В целом, соглашения для платформы определяют, что получающий событие компонент повторно отрисовывает себя. В этом случае инициируется рекурсивная повторная отрисовка компонентов-потомков, значения параметров которых могли измениться.
Дополнительные сведения о том, как соглашения для платформы влияют на производительность и как оптимизировать иерархию компонентов приложения для отрисовки, см. в статье Рекомендации по повышению производительности ASP.NET Core Blazor.
Подавление обновления пользовательского интерфейса ( ShouldRender )
Даже при переопределении ShouldRender компонент всегда проходит первоначальную отрисовку.
Дополнительные сведения о рекомендациях по повышению производительности ShouldRenderсм. в Рекомендации по повышению производительности ASP.NET Core Blazor.
Когда следует вызывать метод StateHasChanged
Вызов метода StateHasChanged позволяет запускать отрисовку в любое время. Тем не менее, метод StateHasChanged не следует вызывать без необходимости. Это распространенная ошибка, которая влечет за собой ненужные затраты ресурсов на отрисовку.
Код не должен вызывать метод StateHasChanged в следующих случаях:
Тем не менее, вызов метода StateHasChanged может требоваться в случаях, которые описываются в следующих разделах этой статьи:
Использование нескольких асинхронных стадий в асинхронном обработчике
Получение вызова извне к системе обработки событий Blazor
ComponentBase имеет сведения только о собственных методах жизненного цикла и событиях, вызываемых Blazor. ComponentBase не располагает информацией о других событиях, которые могут возникать в коде. Например, Blazor не имеет сведений о любых событиях C#, вызываемых пользовательским хранилищем данных. Чтобы такие события вызывали повторную отрисовку для отображения обновленных значений в пользовательском интерфейсе, вызовите метод StateHasChanged.
Поскольку обратный вызов выполняется вне контекста синхронизации Blazor, компонент должен упаковать логику OnTimerCallback в ComponentBase.InvokeAsync, чтобы переместить ее в контекст синхронизации модуля отрисовки. Метод StateHasChanged может вызываться только из контекста синхронизации модуля отрисовки и в противном случае приводит к возникновению исключения. Это поведение эквивалентно маршалингу потока пользовательского интерфейса на других платформах пользовательского интерфейса.
Отрисовка компонента за пределами поддерева, которое повторно отрисовывается в связи с определенным событием
Пользовательский интерфейс может использоваться для выполнения следующих задач:
Одним из способов работы в таких сценариях является предоставление класса управления состоянием, часто в виде службы внедрения зависимостей, внедренной в несколько компонентов. Когда один компонент вызывает метод в диспетчере состояний, диспетчер состояний вызывает событие C#, которое затем получается независимым компонентом.
Поскольку эти события C# выходят за пределы конвейера отрисовки Blazor, следует вызвать метод StateHasChanged для других компонентов, которые необходимо обработать в ответ на события диспетчера состояний.
Компоненты должны отрисовываться при первом добавлении в иерархию компонентов их родительским компонентом. Это единственный случай, когда отрисовка компонента обязательна. Компоненты могут отрисовываться в любых других случаях в соответствии с их собственной логикой и соглашениями.
Соглашения об отрисовке ComponentBase
По умолчанию компоненты Razor наследуются от базового класса ComponentBase, который содержит логику, вызывающую повторную отрисовку в следующие моменты времени:
Компоненты, унаследованные от ComponentBase пропускают повторную отрисовку при обновлении параметров в том случае, если выполняется одно из следующих условий:
Управление потоком отрисовки
В большинстве случаев соглашения для ComponentBase определяют корректное подмножество повторных отрисовок компонента после наступления события. Разработчикам как правило не требуется предоставлять вручную логику, указывающую платформе, какие компоненты и когда следует повторно отрисовывать. В целом, соглашения для платформы определяют, что получающий событие компонент повторно отрисовывает себя. В этом случае инициируется рекурсивная повторная отрисовка компонентов-потомков, значения параметров которых могли измениться.
Дополнительные сведения о том, как соглашения для платформы влияют на производительность и как оптимизировать иерархию компонентов приложения для отрисовки, см. в статье Рекомендации по повышению производительности ASP.NET Core Blazor.
Подавление обновления пользовательского интерфейса ( ShouldRender )
Даже при переопределении ShouldRender компонент всегда проходит первоначальную отрисовку.
Дополнительные сведения о рекомендациях по повышению производительности ShouldRenderсм. в Рекомендации по повышению производительности ASP.NET Core Blazor.
Когда следует вызывать метод StateHasChanged
Вызов метода StateHasChanged позволяет запускать отрисовку в любое время. Тем не менее, метод StateHasChanged не следует вызывать без необходимости. Это распространенная ошибка, которая влечет за собой ненужные затраты ресурсов на отрисовку.
Код не должен вызывать метод StateHasChanged в следующих случаях:
Тем не менее, вызов метода StateHasChanged может требоваться в случаях, которые описываются в следующих разделах этой статьи:
Использование нескольких асинхронных стадий в асинхронном обработчике
Получение вызова извне к системе обработки событий Blazor
ComponentBase имеет сведения только о собственных методах жизненного цикла и событиях, вызываемых Blazor. ComponentBase не располагает информацией о других событиях, которые могут возникать в коде. Например, Blazor не имеет сведений о любых событиях C#, вызываемых пользовательским хранилищем данных. Чтобы такие события вызывали повторную отрисовку для отображения обновленных значений в пользовательском интерфейсе, вызовите метод StateHasChanged.
Поскольку обратный вызов выполняется вне контекста синхронизации Blazor, компонент должен упаковать логику OnTimerCallback в ComponentBase.InvokeAsync, чтобы переместить ее в контекст синхронизации модуля отрисовки. Метод StateHasChanged может вызываться только из контекста синхронизации модуля отрисовки и в противном случае приводит к возникновению исключения. Это поведение эквивалентно маршалингу потока пользовательского интерфейса на других платформах пользовательского интерфейса.
Отрисовка компонента за пределами поддерева, которое повторно отрисовывается в связи с определенным событием
Пользовательский интерфейс может использоваться для выполнения следующих задач:
Одним из способов работы в таких сценариях является предоставление класса управления состоянием, часто в виде службы внедрения зависимостей, внедренной в несколько компонентов. Когда один компонент вызывает метод в диспетчере состояний, диспетчер состояний вызывает событие C#, которое затем получается независимым компонентом.
Поскольку эти события C# выходят за пределы конвейера отрисовки Blazor, следует вызвать метод StateHasChanged для других компонентов, которые необходимо обработать в ответ на события диспетчера состояний.
Компоненты должны отрисовываться при первом добавлении в иерархию компонентов их родительским компонентом. Это единственный случай, когда отрисовка компонента обязательна. Компоненты могут отрисовываться в любых других случаях в соответствии с их собственной логикой и соглашениями.
Соглашения об отрисовке ComponentBase
По умолчанию компоненты Razor наследуются от базового класса ComponentBase, который содержит логику, вызывающую повторную отрисовку в следующие моменты времени:
Компоненты, унаследованные от ComponentBase пропускают повторную отрисовку при обновлении параметров в том случае, если выполняется одно из следующих условий:
Управление потоком отрисовки
В большинстве случаев соглашения для ComponentBase определяют корректное подмножество повторных отрисовок компонента после наступления события. Разработчикам как правило не требуется предоставлять вручную логику, указывающую платформе, какие компоненты и когда следует повторно отрисовывать. В целом, соглашения для платформы определяют, что получающий событие компонент повторно отрисовывает себя. В этом случае инициируется рекурсивная повторная отрисовка компонентов-потомков, значения параметров которых могли измениться.
Дополнительные сведения о том, как соглашения для платформы влияют на производительность и как оптимизировать иерархию компонентов приложения для отрисовки, см. в статье Рекомендации по повышению производительности ASP.NET Core Blazor.
Подавление обновления пользовательского интерфейса ( ShouldRender )
Даже при переопределении ShouldRender компонент всегда проходит первоначальную отрисовку.
Дополнительные сведения о рекомендациях по повышению производительности ShouldRenderсм. в Рекомендации по повышению производительности ASP.NET Core Blazor.
Когда следует вызывать метод StateHasChanged
Вызов метода StateHasChanged позволяет запускать отрисовку в любое время. Тем не менее, метод StateHasChanged не следует вызывать без необходимости. Это распространенная ошибка, которая влечет за собой ненужные затраты ресурсов на отрисовку.
Код не должен вызывать метод StateHasChanged в следующих случаях:
Тем не менее, вызов метода StateHasChanged может требоваться в случаях, которые описываются в следующих разделах этой статьи:
Использование нескольких асинхронных стадий в асинхронном обработчике
Получение вызова извне к системе обработки событий Blazor
ComponentBase имеет сведения только о собственных методах жизненного цикла и событиях, вызываемых Blazor. ComponentBase не располагает информацией о других событиях, которые могут возникать в коде. Например, Blazor не имеет сведений о любых событиях C#, вызываемых пользовательским хранилищем данных. Чтобы такие события вызывали повторную отрисовку для отображения обновленных значений в пользовательском интерфейсе, вызовите метод StateHasChanged.
Поскольку обратный вызов выполняется вне контекста синхронизации Blazor, компонент должен упаковать логику OnTimerCallback в ComponentBase.InvokeAsync, чтобы переместить ее в контекст синхронизации модуля отрисовки. Метод StateHasChanged может вызываться только из контекста синхронизации модуля отрисовки и в противном случае приводит к возникновению исключения. Это поведение эквивалентно маршалингу потока пользовательского интерфейса на других платформах пользовательского интерфейса.
Отрисовка компонента за пределами поддерева, которое повторно отрисовывается в связи с определенным событием
Пользовательский интерфейс может использоваться для выполнения следующих задач:
Одним из способов работы в таких сценариях является предоставление класса управления состоянием, часто в виде службы внедрения зависимостей, внедренной в несколько компонентов. Когда один компонент вызывает метод в диспетчере состояний, диспетчер состояний вызывает событие C#, которое затем получается независимым компонентом.
Поскольку эти события C# выходят за пределы конвейера отрисовки Blazor, следует вызвать метод StateHasChanged для других компонентов, которые необходимо обработать в ответ на события диспетчера состояний.
Управление состоянием ASP.NET Core Blazor
Данные о состоянии пользователя, создаваемые в приложении Blazor WebAssembly, хранятся в памяти браузера.
Ниже приведены примеры данных о состоянии пользователя, хранящиеся в памяти браузера.
Когда пользователь закрывает и повторно открывает браузер или перезагружает страницу, данные о состоянии пользователя, содержащиеся в памяти браузера, утрачиваются.
Защищенное хранилище браузера (пространство имен Microsoft.AspNetCore.Components.Server.ProtectedBrowserStorage) использует защиту данных ASP.NET Core и поддерживается только для приложений Blazor Server.
Сохранение состояния в сеансах браузера
Как правило, состояния поддерживаются между сеансами браузера, где пользователи активно могут создавать данные, а не просто считывать уже существующие данные.
Чтобы сохранять состояние между сеансами браузера, приложение должно хранить данные не в памяти браузера, а в другом месте. Сохраняемость состояния не обеспечивается автоматически. При разработке приложения необходимо выполнить определенные действия для реализации сохраняемости данных с отслеживанием состояния.
Сохраняемость данных, как правило, требуется только для состояний высокой ценности, на создание которых пользователь затратил значительные усилия. В следующих примерах сохранение состояния экономит время или средства в коммерческих действиях.
Приложение может сохранять только состояния приложения. Пользовательские интерфейсы не могут быть сохранены, например экземпляры компонентов и их деревья отрисовки. Компоненты и деревья отрисовки обычно не являются сериализуемыми. Чтобы сохранить состояние пользовательского интерфейса, например развернутые узлы элементов управления иерархического представления, в приложении должен быть пользовательский код для моделирования поведения этого интерфейса как сериализуемого состояния приложения.
Место сохранения состояния
Данные о состоянии могут храниться в общих расположениях:
Хранилище на стороне сервера
Для постоянного хранения данных для нескольких пользователей и устройств приложение может использовать независимое хранилище на стороне сервера, доступ к которому осуществляется через веб-API. Доступны следующие варианты:
После сохранения данных состояние пользователя сохраняется и становится доступным во всех новых сеансах браузера.
Поскольку приложения Blazor WebAssembly полностью выполняются в браузере пользователя, им требуются дополнительные меры для доступа к защищенным внешним системам, например службам хранилища и базам данных. Защита приложений Blazor WebAssembly обеспечивается аналогично защите одностраничных приложений (SPA). Как правило, приложение выполняет проверку подлинности пользователя с помощью OAuth/OpenID Connect (OIDC), а затем взаимодействует со службами хранилища и базами данных, отправляя вызовы веб-API в серверное приложение. Приложение на стороне сервера обеспечивает перенос данных между приложением Blazor WebAssembly и службой хранилища или базой данных. Приложение Blazor WebAssembly поддерживает временное подключение к приложению на стороне сервера, в то время как приложение на стороне сервера подключено к хранилищу постоянно.
Дополнительные сведения см. в следующих ресурсах:
Дополнительные сведения о вариантах хранения данных в Azure см. здесь:
URL-адрес
Для временных данных, представляющих состояние навигации, моделируют данные как часть URL-адреса. Ниже приведены примеры данных о состоянии пользователя, которые моделируются в URL-адресе.
Если пользователь вручную перезагружает страницу, содержимое адресной строки браузера сохраняется.
Сведения об определении шаблонов URL-адресов с помощью директивы @page см. в статье Маршрутизация ASP.NET Core Blazor.
Хранилище браузера
localStorage и sessionStorage можно использовать в приложениях Blazor WebAssembly, но только путем написания пользовательского кода или использования стороннего пакета.
Как правило, sessionStorage более безопасно для использования. sessionStorage позволяет избежать риска, когда пользователь открывает несколько вкладок и сталкивается со следующими проблемами.
localStorage является лучшим выбором, если приложение должно сохранять состояние в случае закрытия и повторного открытия браузера.
Служба контейнеров состояния в памяти
Вложенные компоненты обычно привязываются к данным с помощью цепочки привязки, как описано в статье Привязка к данным в ASP.NET Core Blazor. Вложенные и невложенные компоненты могут иметь общий доступ к данным с помощью зарегистрированного контейнера состояния в памяти. Пользовательский класс контейнера состояния может использовать назначаемое действие Action для уведомления компонентов в других частях приложения об изменениях состояния. В следующем примере:
В Program.cs (Blazor WebAssembly):
В Program.cs (Blazor Server) в ASP.NET Core 6.0 или более поздней версии:
В Startup.ConfigureServices (Blazor Server) в версиях ASP.NET Core, предшествующих версии 6.0:
Дополнительные ресурсы
Blazor Server — это платформа приложений с отслеживанием состояния. В большинстве случаев приложение поддерживает подключение к серверу. Состояние пользователя хранится в памяти сервера в канале.
Ниже приведены примеры данных о состоянии пользователя, хранящиеся в канале.
Данные о состоянии пользователя также можно найти в переменных JavaScript в памяти браузера, заданной с помощью вызовов взаимодействия с JavaScript.
Если пользователь испытывает временный сбой сетевого подключения, Blazor пытается повторно подключить пользователя к исходному каналу с сохранением исходного состояния. Однако повторное подключение пользователя к исходному каналу в памяти сервера не всегда возможно.
Если пользователь не может повторно подключиться к исходному каналу, он получает новый канал с пустым состоянием. Это эквивалентно закрытию и повторному открытию классического приложения.
Сохранение состояния при смене каналов
Как правило, состояния поддерживается при смене каналов, где пользователи активно могут создавать данные, а не просто считывать уже существующие данные.
Чтобы сохранять состояние при смене каналов, приложение должно хранить данные не в памяти сервера, а в другом месте. Сохраняемость состояния не обеспечивается автоматически. При разработке приложения необходимо выполнить определенные действия для реализации сохраняемости данных с отслеживанием состояния.
Сохраняемость данных, как правило, требуется только для состояний высокой ценности, на создание которых пользователь затратил значительные усилия. В следующих примерах сохранение состояния экономит время или средства в коммерческих действиях.
Приложение может сохранять только состояния приложения. Пользовательские интерфейсы не могут быть сохранены, например экземпляры компонентов и их деревья отрисовки. Компоненты и деревья отрисовки обычно не являются сериализуемыми. Чтобы сохранить состояние пользовательского интерфейса, например развернутые узлы элементов управления иерархического представления, в приложении должен быть пользовательский код для моделирования поведения этого интерфейса как сериализуемого состояния приложения.
Место сохранения состояния
Данные о состоянии могут храниться в общих расположениях:
Хранилище на стороне сервера
Для постоянного хранения данных для нескольких пользователей и устройств приложение может использовать хранилище на стороне сервера. Доступны следующие варианты:
После сохранения данных состояние пользователя сохраняется и становится доступным во всех новых каналах.
Дополнительные сведения о вариантах хранения данных в Azure см. здесь:
URL-адрес
Для временных данных, представляющих состояние навигации, моделируют данные как часть URL-адреса. Ниже приведены примеры данных о состоянии пользователя, которые моделируются в URL-адресе.
Содержимое адресной строки браузера будет сохраняться в следующих случаях.
Сведения об определении шаблонов URL-адресов с помощью директивы @page см. в статье Маршрутизация ASP.NET Core Blazor.
Хранилище браузера
Как правило, sessionStorage более безопасно для использования. sessionStorage позволяет избежать риска, когда пользователь открывает несколько вкладок и сталкивается со следующими проблемами.
localStorage является лучшим выбором, если приложение должно сохранять состояние в случае закрытия и повторного открытия браузера.
Предостережения при использовании хранилища браузера.
Защищенное хранилище браузера ASP.NET Core
Защищенное хранилище браузера использует защиту данных ASP.NET Core и поддерживается только для приложений Blazor Server.
Сохранение и загрузка данных в компоненте
В любом компоненте, требующем загрузки или сохранения данных в хранилище браузера, используйте директиву @inject для вставки экземпляра одного из следующих компонентов.
В больших и более реалистичных приложениях хранение отдельных полей является маловероятной ситуацией. Приложения, скорее всего, будут хранить все объекты модели, включающие сложное состояние. ProtectedSessionStore автоматически сериализует и десериализует данные JSON для хранения объектов со сложными состояниями.
В предыдущем примере кода данные currentCount хранятся в виде sessionStorage[‘count’] в браузере пользователя. Данные не хранятся в виде обычного текста, а защищаются с помощью функции защиты данных ASP.NET Core. Зашифрованные данные можно проверить, если sessionStorage[‘count’] вычисляется в консоли разработчика браузера.
Если параметры компонента включают состояние навигации, вызовите ProtectedSessionStore.GetAsync и назначьте отличный от null результат в OnParametersSetAsync, а не в OnInitializedAsync. OnInitializedAsync вызывается только один раз при первом создании экземпляра компонента. OnInitializedAsync не вызывается позже, если пользователь переходит на другой URL-адрес, оставаясь на той же странице. Для получения дополнительной информации см. Жизненный цикл компонента Razor ASP.NET Core.
Примеры в этом разделе работают только в том случае, если на сервере не включена предварительная отрисовка. При включенной предварительной отрисовке выводится сообщение об ошибке, объясняющее, что вызовы взаимодействия с JavaScript осуществить невозможно, поскольку выполняется предварительная отрисовка компонента.
Отключите предварительную отрисовку или добавьте дополнительный код для работы с предварительной отрисовкой. Дополнительные сведения о написании кода, который работает с предварительной отрисовкой, см. в разделе Обработка предварительной отрисовки.
Обработка состояния загрузки
Так как доступ к хранилищу браузера осуществляется асинхронно через сетевое подключение, всегда есть период времени, прежде чем данные будут загружены и станут доступны для компонента. Для достижения лучших результатов перед отображением пустых данных или данных по умолчанию выводится сообщение о состоянии загрузки.
Вместо безусловного отображения количества и кнопки Increment отображайте эти элементы только в том случае, если данные загружены, указав HasValue.
Обработка предварительной отрисовки
Во время предварительной отрисовки происходит следующее:
localStorage или sessionStorage недоступны во время предварительной отрисовки. Если компонент пытается взаимодействовать с хранилищем, выводится сообщение об ошибке, объясняющее, что вызовы взаимодействия с JavaScript осуществить невозможно, поскольку выполняется предварительная отрисовка компонента.
Чтобы отключить предварительную отрисовку, откройте файл Pages/_Host.cshtml и измените атрибут render-mode вспомогательной функции тега компонента на Server.
Перенос сохранения состояния в общее расположение
Если многие компоненты используют хранилище на основе браузера, повторная реализация кода поставщика состояний много раз создает дублирование кода. Одним из вариантов предотвращения дублирования кода является создание родительского компонента поставщика состояний, который инкапсулирует логику поставщика состояний. Дочерние компоненты могут работать с сохраненными данными без учета механизма сохранения состояния.
Компонент CounterStateProvider обрабатывает этап загрузки, не выполняя отрисовку его дочернего содержимого до завершения загрузки.
Упакованные компоненты получают и могут изменять состояние сохраненного счетчика. Следующий компонент Counter реализует этот шаблон.
Предыдущий компонент не требуется для взаимодействия с ProtectedBrowserStorage и не имеет отношения к этапу «загрузки».
Для работы с предварительной отрисовкой, как описано выше, CounterStateProvider можно сделать так, чтобы все компоненты, использующие данные счетчика, автоматически работали с предварительной отрисовкой. Дополнительные сведения см. в разделе Обработка предварительной отрисовки.
В целом шаблон родительского компонента поставщика состояний рекомендуется использовать в следующих случаях:
Чтобы сохранить множество различных объектов состояния и использовать разные подмножества объектов в разных местах, лучше избегать глобального сохранения состояния.
Служба контейнеров состояния в памяти
Вложенные компоненты обычно привязываются к данным с помощью цепочки привязки, как описано в статье Привязка к данным в ASP.NET Core Blazor. Вложенные и невложенные компоненты могут иметь общий доступ к данным с помощью зарегистрированного контейнера состояния в памяти. Пользовательский класс контейнера состояния может использовать назначаемое действие Action для уведомления компонентов в других частях приложения об изменениях состояния. В следующем примере:
В Program.cs (Blazor WebAssembly):
В Program.cs (Blazor Server) в ASP.NET Core 6.0 или более поздней версии:
В Startup.ConfigureServices (Blazor Server) в версиях ASP.NET Core, предшествующих версии 6.0:
Данные о состоянии пользователя, создаваемые в приложении Blazor WebAssembly, хранятся в памяти браузера.
Ниже приведены примеры данных о состоянии пользователя, хранящиеся в памяти браузера.
Когда пользователь закрывает и повторно открывает браузер или перезагружает страницу, данные о состоянии пользователя, содержащиеся в памяти браузера, утрачиваются.
Защищенное хранилище браузера (пространство имен Microsoft.AspNetCore.Components.Server.ProtectedBrowserStorage) использует защиту данных ASP.NET Core и поддерживается только для приложений Blazor Server.
Сохранение состояния в сеансах браузера
Как правило, состояния поддерживаются между сеансами браузера, где пользователи активно могут создавать данные, а не просто считывать уже существующие данные.
Чтобы сохранять состояние между сеансами браузера, приложение должно хранить данные не в памяти браузера, а в другом месте. Сохраняемость состояния не обеспечивается автоматически. При разработке приложения необходимо выполнить определенные действия для реализации сохраняемости данных с отслеживанием состояния.
Сохраняемость данных, как правило, требуется только для состояний высокой ценности, на создание которых пользователь затратил значительные усилия. В следующих примерах сохранение состояния экономит время или средства в коммерческих действиях.
Приложение может сохранять только состояния приложения. Пользовательские интерфейсы не могут быть сохранены, например экземпляры компонентов и их деревья отрисовки. Компоненты и деревья отрисовки обычно не являются сериализуемыми. Чтобы сохранить состояние пользовательского интерфейса, например развернутые узлы элементов управления иерархического представления, в приложении должен быть пользовательский код для моделирования поведения этого интерфейса как сериализуемого состояния приложения.
Место сохранения состояния
Данные о состоянии могут храниться в общих расположениях:
Хранилище на стороне сервера
Для постоянного хранения данных для нескольких пользователей и устройств приложение может использовать независимое хранилище на стороне сервера, доступ к которому осуществляется через веб-API. Доступны следующие варианты:
После сохранения данных состояние пользователя сохраняется и становится доступным во всех новых сеансах браузера.
Поскольку приложения Blazor WebAssembly полностью выполняются в браузере пользователя, им требуются дополнительные меры для доступа к защищенным внешним системам, например службам хранилища и базам данных. Защита приложений Blazor WebAssembly обеспечивается аналогично защите одностраничных приложений (SPA). Как правило, приложение выполняет проверку подлинности пользователя с помощью OAuth/OpenID Connect (OIDC), а затем взаимодействует со службами хранилища и базами данных, отправляя вызовы веб-API в серверное приложение. Приложение на стороне сервера обеспечивает перенос данных между приложением Blazor WebAssembly и службой хранилища или базой данных. Приложение Blazor WebAssembly поддерживает временное подключение к приложению на стороне сервера, в то время как приложение на стороне сервера подключено к хранилищу постоянно.
Дополнительные сведения см. в следующих ресурсах:
Дополнительные сведения о вариантах хранения данных в Azure см. здесь:
URL-адрес
Для временных данных, представляющих состояние навигации, моделируют данные как часть URL-адреса. Ниже приведены примеры данных о состоянии пользователя, которые моделируются в URL-адресе.
Если пользователь вручную перезагружает страницу, содержимое адресной строки браузера сохраняется.
Сведения об определении шаблонов URL-адресов с помощью директивы @page см. в статье Маршрутизация ASP.NET Core Blazor.
Хранилище браузера
localStorage и sessionStorage можно использовать в приложениях Blazor WebAssembly, но только путем написания пользовательского кода или использования стороннего пакета.
Как правило, sessionStorage более безопасно для использования. sessionStorage позволяет избежать риска, когда пользователь открывает несколько вкладок и сталкивается со следующими проблемами.
localStorage является лучшим выбором, если приложение должно сохранять состояние в случае закрытия и повторного открытия браузера.
Служба контейнеров состояния в памяти
Вложенные компоненты обычно привязываются к данным с помощью цепочки привязки, как описано в статье Привязка к данным в ASP.NET Core Blazor. Вложенные и невложенные компоненты могут иметь общий доступ к данным с помощью зарегистрированного контейнера состояния в памяти. Пользовательский класс контейнера состояния может использовать назначаемое действие Action для уведомления компонентов в других частях приложения об изменениях состояния. В следующем примере:
В Program.cs (Blazor WebAssembly):
В Program.cs (Blazor Server) в ASP.NET Core 6.0 или более поздней версии:
В Startup.ConfigureServices (Blazor Server) в версиях ASP.NET Core, предшествующих версии 6.0:
Дополнительные ресурсы
Blazor Server — это платформа приложений с отслеживанием состояния. В большинстве случаев приложение поддерживает подключение к серверу. Состояние пользователя хранится в памяти сервера в канале.
Ниже приведены примеры данных о состоянии пользователя, хранящиеся в канале.
Данные о состоянии пользователя также можно найти в переменных JavaScript в памяти браузера, заданной с помощью вызовов взаимодействия с JavaScript.
Если пользователь испытывает временный сбой сетевого подключения, Blazor пытается повторно подключить пользователя к исходному каналу с сохранением исходного состояния. Однако повторное подключение пользователя к исходному каналу в памяти сервера не всегда возможно.
Если пользователь не может повторно подключиться к исходному каналу, он получает новый канал с пустым состоянием. Это эквивалентно закрытию и повторному открытию классического приложения.
Сохранение состояния при смене каналов
Как правило, состояния поддерживается при смене каналов, где пользователи активно могут создавать данные, а не просто считывать уже существующие данные.
Чтобы сохранять состояние при смене каналов, приложение должно хранить данные не в памяти сервера, а в другом месте. Сохраняемость состояния не обеспечивается автоматически. При разработке приложения необходимо выполнить определенные действия для реализации сохраняемости данных с отслеживанием состояния.
Сохраняемость данных, как правило, требуется только для состояний высокой ценности, на создание которых пользователь затратил значительные усилия. В следующих примерах сохранение состояния экономит время или средства в коммерческих действиях.
Приложение может сохранять только состояния приложения. Пользовательские интерфейсы не могут быть сохранены, например экземпляры компонентов и их деревья отрисовки. Компоненты и деревья отрисовки обычно не являются сериализуемыми. Чтобы сохранить состояние пользовательского интерфейса, например развернутые узлы элементов управления иерархического представления, в приложении должен быть пользовательский код для моделирования поведения этого интерфейса как сериализуемого состояния приложения.
Место сохранения состояния
Данные о состоянии могут храниться в общих расположениях:
Хранилище на стороне сервера
Для постоянного хранения данных для нескольких пользователей и устройств приложение может использовать хранилище на стороне сервера. Доступны следующие варианты:
После сохранения данных состояние пользователя сохраняется и становится доступным во всех новых каналах.
Дополнительные сведения о вариантах хранения данных в Azure см. здесь:
URL-адрес
Для временных данных, представляющих состояние навигации, моделируют данные как часть URL-адреса. Ниже приведены примеры данных о состоянии пользователя, которые моделируются в URL-адресе.
Содержимое адресной строки браузера будет сохраняться в следующих случаях.
Сведения об определении шаблонов URL-адресов с помощью директивы @page см. в статье Маршрутизация ASP.NET Core Blazor.
Хранилище браузера
Как правило, sessionStorage более безопасно для использования. sessionStorage позволяет избежать риска, когда пользователь открывает несколько вкладок и сталкивается со следующими проблемами.
localStorage является лучшим выбором, если приложение должно сохранять состояние в случае закрытия и повторного открытия браузера.
Предостережения при использовании хранилища браузера.
Защищенное хранилище браузера ASP.NET Core
Защищенное хранилище браузера использует защиту данных ASP.NET Core и поддерживается только для приложений Blazor Server.
Сохранение и загрузка данных в компоненте
В любом компоненте, требующем загрузки или сохранения данных в хранилище браузера, используйте директиву @inject для вставки экземпляра одного из следующих компонентов.
В больших и более реалистичных приложениях хранение отдельных полей является маловероятной ситуацией. Приложения, скорее всего, будут хранить все объекты модели, включающие сложное состояние. ProtectedSessionStore автоматически сериализует и десериализует данные JSON для хранения объектов со сложными состояниями.
В предыдущем примере кода данные currentCount хранятся в виде sessionStorage[‘count’] в браузере пользователя. Данные не хранятся в виде обычного текста, а защищаются с помощью функции защиты данных ASP.NET Core. Зашифрованные данные можно проверить, если sessionStorage[‘count’] вычисляется в консоли разработчика браузера.
Если параметры компонента включают состояние навигации, вызовите ProtectedSessionStore.GetAsync и назначьте отличный от null результат в OnParametersSetAsync, а не в OnInitializedAsync. OnInitializedAsync вызывается только один раз при первом создании экземпляра компонента. OnInitializedAsync не вызывается позже, если пользователь переходит на другой URL-адрес, оставаясь на той же странице. Для получения дополнительной информации см. Жизненный цикл компонента Razor ASP.NET Core.
Примеры в этом разделе работают только в том случае, если на сервере не включена предварительная отрисовка. При включенной предварительной отрисовке выводится сообщение об ошибке, объясняющее, что вызовы взаимодействия с JavaScript осуществить невозможно, поскольку выполняется предварительная отрисовка компонента.
Отключите предварительную отрисовку или добавьте дополнительный код для работы с предварительной отрисовкой. Дополнительные сведения о написании кода, который работает с предварительной отрисовкой, см. в разделе Обработка предварительной отрисовки.
Обработка состояния загрузки
Так как доступ к хранилищу браузера осуществляется асинхронно через сетевое подключение, всегда есть период времени, прежде чем данные будут загружены и станут доступны для компонента. Для достижения лучших результатов перед отображением пустых данных или данных по умолчанию выводится сообщение о состоянии загрузки.
Вместо безусловного отображения количества и кнопки Increment отображайте эти элементы только в том случае, если данные загружены, указав HasValue.
Обработка предварительной отрисовки
Во время предварительной отрисовки происходит следующее:
localStorage или sessionStorage недоступны во время предварительной отрисовки. Если компонент пытается взаимодействовать с хранилищем, выводится сообщение об ошибке, объясняющее, что вызовы взаимодействия с JavaScript осуществить невозможно, поскольку выполняется предварительная отрисовка компонента.
Чтобы отключить предварительную отрисовку, откройте файл Pages/_Host.cshtml и измените атрибут render-mode вспомогательной функции тега компонента на Server.
Перенос сохранения состояния в общее расположение
Если многие компоненты используют хранилище на основе браузера, повторная реализация кода поставщика состояний много раз создает дублирование кода. Одним из вариантов предотвращения дублирования кода является создание родительского компонента поставщика состояний, который инкапсулирует логику поставщика состояний. Дочерние компоненты могут работать с сохраненными данными без учета механизма сохранения состояния.
Компонент CounterStateProvider обрабатывает этап загрузки, не выполняя отрисовку его дочернего содержимого до завершения загрузки.
Упакованные компоненты получают и могут изменять состояние сохраненного счетчика. Следующий компонент Counter реализует этот шаблон.
Предыдущий компонент не требуется для взаимодействия с ProtectedBrowserStorage и не имеет отношения к этапу «загрузки».
Для работы с предварительной отрисовкой, как описано выше, CounterStateProvider можно сделать так, чтобы все компоненты, использующие данные счетчика, автоматически работали с предварительной отрисовкой. Дополнительные сведения см. в разделе Обработка предварительной отрисовки.
В целом шаблон родительского компонента поставщика состояний рекомендуется использовать в следующих случаях:
Чтобы сохранить множество различных объектов состояния и использовать разные подмножества объектов в разных местах, лучше избегать глобального сохранения состояния.
Служба контейнеров состояния в памяти
Вложенные компоненты обычно привязываются к данным с помощью цепочки привязки, как описано в статье Привязка к данным в ASP.NET Core Blazor. Вложенные и невложенные компоненты могут иметь общий доступ к данным с помощью зарегистрированного контейнера состояния в памяти. Пользовательский класс контейнера состояния может использовать назначаемое действие Action для уведомления компонентов в других частях приложения об изменениях состояния. В следующем примере:
В Program.cs (Blazor WebAssembly):
В Program.cs (Blazor Server) в ASP.NET Core 6.0 или более поздней версии:
В Startup.ConfigureServices (Blazor Server) в версиях ASP.NET Core, предшествующих версии 6.0:
Данные о состоянии пользователя, создаваемые в приложении Blazor WebAssembly, хранятся в памяти браузера.
Ниже приведены примеры данных о состоянии пользователя, хранящиеся в памяти браузера.
Когда пользователь закрывает и повторно открывает браузер или перезагружает страницу, данные о состоянии пользователя, содержащиеся в памяти браузера, утрачиваются.
Защищенное хранилище браузера (пространство имен Microsoft.AspNetCore.Components.Server.ProtectedBrowserStorage) использует защиту данных ASP.NET Core и поддерживается только для приложений Blazor Server.
Сохранение состояния в сеансах браузера
Как правило, состояния поддерживаются между сеансами браузера, где пользователи активно могут создавать данные, а не просто считывать уже существующие данные.
Чтобы сохранять состояние между сеансами браузера, приложение должно хранить данные не в памяти браузера, а в другом месте. Сохраняемость состояния не обеспечивается автоматически. При разработке приложения необходимо выполнить определенные действия для реализации сохраняемости данных с отслеживанием состояния.
Сохраняемость данных, как правило, требуется только для состояний высокой ценности, на создание которых пользователь затратил значительные усилия. В следующих примерах сохранение состояния экономит время или средства в коммерческих действиях.
Приложение может сохранять только состояния приложения. Пользовательские интерфейсы не могут быть сохранены, например экземпляры компонентов и их деревья отрисовки. Компоненты и деревья отрисовки обычно не являются сериализуемыми. Чтобы сохранить состояние пользовательского интерфейса, например развернутые узлы элементов управления иерархического представления, в приложении должен быть пользовательский код для моделирования поведения этого интерфейса как сериализуемого состояния приложения.
Место сохранения состояния
Данные о состоянии могут храниться в общих расположениях:
Хранилище на стороне сервера
Для постоянного хранения данных для нескольких пользователей и устройств приложение может использовать независимое хранилище на стороне сервера, доступ к которому осуществляется через веб-API. Доступны следующие варианты:
После сохранения данных состояние пользователя сохраняется и становится доступным во всех новых сеансах браузера.
Поскольку приложения Blazor WebAssembly полностью выполняются в браузере пользователя, им требуются дополнительные меры для доступа к защищенным внешним системам, например службам хранилища и базам данных. Защита приложений Blazor WebAssembly обеспечивается аналогично защите одностраничных приложений (SPA). Как правило, приложение выполняет проверку подлинности пользователя с помощью OAuth/OpenID Connect (OIDC), а затем взаимодействует со службами хранилища и базами данных, отправляя вызовы веб-API в серверное приложение. Приложение на стороне сервера обеспечивает перенос данных между приложением Blazor WebAssembly и службой хранилища или базой данных. Приложение Blazor WebAssembly поддерживает временное подключение к приложению на стороне сервера, в то время как приложение на стороне сервера подключено к хранилищу постоянно.
Дополнительные сведения см. в следующих ресурсах:
Дополнительные сведения о вариантах хранения данных в Azure см. здесь:
URL-адрес
Для временных данных, представляющих состояние навигации, моделируют данные как часть URL-адреса. Ниже приведены примеры данных о состоянии пользователя, которые моделируются в URL-адресе.
Если пользователь вручную перезагружает страницу, содержимое адресной строки браузера сохраняется.
Сведения об определении шаблонов URL-адресов с помощью директивы @page см. в статье Маршрутизация ASP.NET Core Blazor.
Хранилище браузера
localStorage и sessionStorage можно использовать в приложениях Blazor WebAssembly, но только путем написания пользовательского кода или использования стороннего пакета.
Как правило, sessionStorage более безопасно для использования. sessionStorage позволяет избежать риска, когда пользователь открывает несколько вкладок и сталкивается со следующими проблемами.
localStorage является лучшим выбором, если приложение должно сохранять состояние в случае закрытия и повторного открытия браузера.
Служба контейнеров состояния в памяти
Вложенные компоненты обычно привязываются к данным с помощью цепочки привязки, как описано в статье Привязка к данным в ASP.NET Core Blazor. Вложенные и невложенные компоненты могут иметь общий доступ к данным с помощью зарегистрированного контейнера состояния в памяти. Пользовательский класс контейнера состояния может использовать назначаемое действие Action для уведомления компонентов в других частях приложения об изменениях состояния. В следующем примере:
В Program.cs (Blazor WebAssembly):
В Program.cs (Blazor Server) в ASP.NET Core 6.0 или более поздней версии:
В Startup.ConfigureServices (Blazor Server) в версиях ASP.NET Core, предшествующих версии 6.0:
Дополнительные ресурсы
Blazor Server — это платформа приложений с отслеживанием состояния. В большинстве случаев приложение поддерживает подключение к серверу. Состояние пользователя хранится в памяти сервера в канале.
Ниже приведены примеры данных о состоянии пользователя, хранящиеся в канале.
Данные о состоянии пользователя также можно найти в переменных JavaScript в памяти браузера, заданной с помощью вызовов взаимодействия с JavaScript.
Если пользователь испытывает временный сбой сетевого подключения, Blazor пытается повторно подключить пользователя к исходному каналу с сохранением исходного состояния. Однако повторное подключение пользователя к исходному каналу в памяти сервера не всегда возможно.
Если пользователь не может повторно подключиться к исходному каналу, он получает новый канал с пустым состоянием. Это эквивалентно закрытию и повторному открытию классического приложения.
Сохранение состояния при смене каналов
Как правило, состояния поддерживается при смене каналов, где пользователи активно могут создавать данные, а не просто считывать уже существующие данные.
Чтобы сохранять состояние при смене каналов, приложение должно хранить данные не в памяти сервера, а в другом месте. Сохраняемость состояния не обеспечивается автоматически. При разработке приложения необходимо выполнить определенные действия для реализации сохраняемости данных с отслеживанием состояния.
Сохраняемость данных, как правило, требуется только для состояний высокой ценности, на создание которых пользователь затратил значительные усилия. В следующих примерах сохранение состояния экономит время или средства в коммерческих действиях.
Приложение может сохранять только состояния приложения. Пользовательские интерфейсы не могут быть сохранены, например экземпляры компонентов и их деревья отрисовки. Компоненты и деревья отрисовки обычно не являются сериализуемыми. Чтобы сохранить состояние пользовательского интерфейса, например развернутые узлы элементов управления иерархического представления, в приложении должен быть пользовательский код для моделирования поведения этого интерфейса как сериализуемого состояния приложения.
Место сохранения состояния
Данные о состоянии могут храниться в общих расположениях:
Хранилище на стороне сервера
Для постоянного хранения данных для нескольких пользователей и устройств приложение может использовать хранилище на стороне сервера. Доступны следующие варианты:
После сохранения данных состояние пользователя сохраняется и становится доступным во всех новых каналах.
Дополнительные сведения о вариантах хранения данных в Azure см. здесь:
URL-адрес
Для временных данных, представляющих состояние навигации, моделируют данные как часть URL-адреса. Ниже приведены примеры данных о состоянии пользователя, которые моделируются в URL-адресе.
Содержимое адресной строки браузера будет сохраняться в следующих случаях.
Сведения об определении шаблонов URL-адресов с помощью директивы @page см. в статье Маршрутизация ASP.NET Core Blazor.
Хранилище браузера
Как правило, sessionStorage более безопасно для использования. sessionStorage позволяет избежать риска, когда пользователь открывает несколько вкладок и сталкивается со следующими проблемами.
localStorage является лучшим выбором, если приложение должно сохранять состояние в случае закрытия и повторного открытия браузера.
Предостережения при использовании хранилища браузера.