Узнайте, как повторно использовать состояние между предварительным рендерингом и установлением интерактивности в компонентах Blazor.
В Blazor предварительный рендеринг позволяет быстро отображать страницы на сервере, предоставляя пользователям полезный контент до того, как приложение станет интерактивным. Он также делает начальный HTML-код доступным для поисковых систем.
Однако предварительный рендеринг имеет важное следствие: компонент может быть инициализирован дважды. Сначала он рендерится на сервере в процессе предварительного рендеринга, а затем инициализируется снова, когда вступает в силу выбранный режим интерактивного рендеринга. Это относится не только к Interactive Server, но также к Interactive WebAssembly и Interactive Auto.
Это может стать проблемой, когда компонент выполняет ресурсоемкие операции во время инициализации, такие как обращение к базе данных или внешнему API.
В этой статье мы узнаем, как избежать этой ненужной работы путем сохранения состояния компонента между предварительным рендерингом и интерактивным рендерингом.
Вы можете получить доступ к коду на GitHub.
Поведение по умолчанию для компонентов страниц и предварительного рендеринга в Blazor
Мы часто видим такой код в компонентах страниц:
Проблема здесь заключается в том, что при включенном предварительном рендеринге метод жизненного цикла OnInitializedAsync будет вызываться дважды. Если данные, предоставляемые сервисом, одинаковы, пользователь может не заметить никаких изменений на экране.
Однако представьте следующую реализацию метода GetProductsAsync:
В этом примере используются случайно сгенерированные значения для свойства Price каждого продукта. То, что сначала может показаться немного искусственным, на самом деле имеет полный смысл. Позвольте мне объяснить.
Мы симулируем загрузку запасов из внешнего API или цены из удаленного сервиса. Нет гарантии, что продукт стоит одинаково в течение всего дня или что другой пользователь не приобрел продукт в промежутке между двумя вызовами GetProductsAsync.
Если мы добавим оператор логирования в метод GetProductsAsync, мы увидим, что метод вызывается дважды во время загрузки страницы.
На экране пользователь увидит две разные цены на один и тот же товар. Первое значение появляется быстро, а затем второе заменяет его.
Это экран после предварительного рендеринга.
А это экран после того, как интерактивность компонента была инициализирована.
Жизненный цикл компонента Blazor с предварительным рендерингом
Давайте сделаем шаг назад и посмотрим, как и почему метод OnInitializedAsync вызывается дважды при рендеринге страницы в веб-приложении Blazor с включенным предварительным рендерингом.
Пользователь инициирует HTTP-запрос, посещая веб-приложение через браузер. Сервер выполняет предварительный рендеринг начальной страницы и отправляет HTML клиенту, где браузер отображает его.
Тем временем Blazor становится интерактивным, и компонент переинициализируется. Например, включаются обработчики кликов.
Компонент инициализируется один раз во время предварительного рендеринга, а затем инициализируется снова, когда вступает в силу режим интерактивного рендеринга. В результате OnInitializedAsync может выполняться дважды, из-за чего код, выполняющий загрузку данных или другие действия по инициализации, выполняется дважды.
Это поведение одинаково независимо от режима рендеринга (InteractiveServer, InteractiveWebAssembly, InteractiveAuto).
Сохранение предварительно сгенерированного состояния между вызовами OnInitializedAsync
Теперь, когда мы понимаем, что происходит, давайте узнаем, как исправить эту проблему. В нашем примере кода мы хотим получить данные из ProductService только один раз.
Простое решение заключается в том, чтобы сохранить данные в свойстве Data во время предварительного рендеринга и сделать их доступными для повторного использования, когда компонент станет интерактивным и метод OnInitializedAsync будет вызван снова.
Сначала давайте убедимся, что мы проверяем, не равно ли свойство Data нулю, прежде чем обращаться к ProductService.
Но как сохранить данные в свойстве Data после их получения из ProductService путем вызова его метода GetProductsAsync?
Это именно та проблема, которую помогает решить атрибут PersistentState в .NET 10.
Мы добавляем атрибут PersistentState к свойству Data.
Это все, что нам нужно сделать. Когда вы перезапустите приложение, вы заметите, что цены не меняются при перезагрузке страницы продуктов.
Под капотом данные внутри свойства Data будут сериализованы, чтобы их можно было десериализовать во время второго вызова OnInitializedAsync. Blazor сохраняет не сам компонент. Он сохраняет значение свойства.
Примечание: вы можете добавить операторы логирования в метод жизненного цикла OnInitializedAsync и метод GetProductsAsync сервиса ProductService. Вы заметите, что примененный атрибут PersistentState приводит к двум вызовам OnInitializedAsync и только одному вызову GetProductsAsync. Напротив, без атрибута PersistentState вызов GetProductsAsync будет происходить для каждого вызова метода OnInitializedAsync.
Какие данные следует сохранять?
Данные, возвращаемые бэкенд-API, являются очевидным кандидатом на сохранение между предварительным рендерингом и интерактивностью компонента. Но как насчет других данных?
Следующий список представляет собой мое личное руководство, которое поможет вам понять, когда следует использовать или избегать использования атрибута PersistentState в ваших проектах:
Хорошие кандидаты
- Данные, полученные во время предварительного рендеринга
- Ресурсоемкие для создания сериализуемые данные моделей представления
- Данные справочников только для чтения
- Начальное состояние формы
- Данные, необходимые для того, чтобы интерактивный пользовательский интерфейс соответствовал интерфейсу предварительного рендеринга
Плохие кандидаты
- Пароли
- Секреты
- Огромные наборы данных
- Конфиденциальная информация
- Объекты, содержащие инфраструктурные зависимости
- Вещи, которым действительно место в базе данных
Здесь есть важный аспект безопасности. При клиентском рендеринге сохраненное состояние доступно в браузере, поэтому не включайте конфиденциальную/приватную информацию.
При интерактивном серверном рендеринге Core Data Protection защищает передаваемые данные, но вам все равно нужно тщательно обдумывать, что именно вы сохраняете. Для InteractiveAuto и InteractiveWebAssembly необходимо учитывать правила экспозиции на стороне клиента.
Совет: если состояние должно поступить в компонент Interactive WebAssembly, предполагайте, что сохраненное представление в конечном итоге может быть просмотрено клиентом. Не используйте сохраненное состояние компонентов в качестве механизма сокрытия секретов, информации об авторизации, паролей или других конфиденциальных данных.
Состояние в веб-приложениях Blazor
Атрибут PersistentState решает именно ту задачу, о которой говорится в этой статье. Он сохраняет состояние компонента между предварительным рендерингом и интерактивностью компонента.
В веб-приложениях Blazor нам приходится работать с различными типами состояния. Атрибут PersistentState — это лишь небольшая часть большой головоломки.
В следующей таблице показаны различные типы состояния, конкретный пример и передовой метод работы с этим состоянием.
Атрибут PersistentState следует использовать только для сохранения состояния между предварительным рендерингом компонента и инициализацией его интерактивности.
Заключение
Предварительный рендеринг является важной частью создания быстрых веб-приложений Blazor, но он также означает, что компоненты могут инициализироваться более одного раза по мере перехода от предварительно сгенерированного HTML к интерактивному приложению.
Если инициализация компонента выполняет ресурсоемкие операции, такие как получение данных из бэкенд-сервиса или базы данных, эти операции могут быть выполнены дважды, когда компонент становится интерактивным.
Атрибут PersistentState предоставляет простой способ сохранения данных, возвращаемых серверной службой между этими двумя фазами, позволяя интерактивному компоненту повторно использовать данные, которые уже были получены во время предварительного рендеринга.
Однако PersistentState не является заменой других подходов к управлению состоянием в Blazor. Он особенно полезен для переноса состояния через границу между предварительным рендерингом и интерактивным рендерингом.
Если вы хотите узнать больше о разработке на Blazor, посмотрите мой бесплатный экспресс-курс по Blazor на YouTube. И следите за обновлениями в блоге Telerik, чтобы узнать больше об основах Blazor.
