ИССЛЕДОВАНИЕ ПРИНЦИПОВ РАБОТЫ ИНСТРУМЕНТОВ УПРАВЛЕНИЯ СОСТОЯНИЕМ В REACT

EXPLORING THE PRINCIPLES OF STATE MANAGEMENT TOOLS IN REACT

Maxim Beryanov

Student, PIKT faculty, ITMO University,

Russia, Saint-Petersburg

АННОТАЦИЯ

Состояние – это собирательное понятие для любой информации, имеющей отношение к приложению. В рамках библиотеки React и концепции реактивности проблема состояния и его обновления является далеко не тривиальной задачей – существует множество библиотек, решающих данную проблему. В этой статье будет уместным исследовать внутреннюю работу таких библиотек и выявить базовый принцип отслеживания изменений.

ABSTRACT

State is a collective term for any information that is relevant to an application. Within React library and the concept of reactivity, the problem of state and updating it is far from a trivial task - there are many libraries that solve this problem. In this article, it will be appropriate to explore the inner mechanism of such libraries and identify basic principle of tracking changes.

Ключевые слова: состояние, React, наблюдатель, поставщик.

Keywords: state, React, observer, provider.

Уже долгое время возникает вопрос, что отличает React Context API [1] (управление состоянием на основе React) от других инструментов управления состоянием, таких как Redux [2] или Recoil [3]. Если мы посмотрим документацию по этим инструментам, мы увидим нечто общее, а именно то, что эти инструменты релевантны для приложения с часто изменяющимся глобальным состоянием.

Redux и Recoil, например, постоянно говорят своим пользователям, что им может не понадобиться использовать инструмент, если у них имеется небольшое приложение с небольшим количеством компонентов, и их состояние меняется редко – в таком случае может подойти Context API.

Как мы знаем, Context API не совсем идеален с точки зрения производительности по простой причине – когда любое состояние в Provider (поставщике состояния) изменяется, все дочерние компоненты внутри этого Provider будут повторно отрисовываться (перерисовываться). Это делает использование Context API в качестве управления состоянием неэффективным, потому что снижает производительность нашего приложения. Конечно, если мы говорим про такой вариант использования, как изменение цветовой схемы в контексте некоторого статического состояния, для этого совершенно уместно использование React Context API.

Каждый компонент React автоматически перерисовывается по трем простым причинам: 1) когда состояние компонента изменяется, даже если это состояние извлекается из пользовательских хуков, таких как useQuery() или useContext(); 2) когда свойства компонента изменяются; 3) когда родительский компонент выполняет свое перерисовывание, он вызывает аналогичный эффект у всех дочерних компонентов, особенно если эти подкомпоненты не обернуты оптимизационной функцией memo. Ненужные повторные отрисовки влияют на производительность приложения и приводят к потере заряда батареи устройства, чего, конечно же, не хочет ни один пользователь. Давайте подробно рассмотрим, почему компоненты перерисовываются и как предотвратить нежелательный повторный рендеринг для оптимизации компонентов приложения.

Redux и другие инструменты управления состоянием, такие как Recoil, пытаются построить оптимизированную систему обнаружения изменений (Observer) в React. Часто инструменты полагаются на различные технологии: Recoil основывается на Graph и Set, а Redux больше ориентирован на Plain Object с более продвинутыми редукторами для сложных изменений состояния.

Система обнаружения изменений представляет собой шаблон проектирования, хранящий состояние и наблюдателей-подписчиков, реагирующих через обратные вызовы, и система автоматически уведомляет этих зарегистрированных наблюдателей, когда состояние изменяется.

Архитектура Observer состоит из трех основных компонентов: состояние или данные, зарегистрированные подписчики/наблюдатели в виде агрегированных обратных вызовов и редактор состояния, которым мы можем изменить состояние. Данный редактор не просто изменяет состояние, но также пытается уведомить всех зарегистрированных подписчиков/наблюдателей об его изменении – это сильно отличается от системы публикации/подписки [4], которая позволяет определять события, которые мы можем отправлять подписчикам с необходимой информацией.

Очевидно, что подписчик ­– это обратный вызов, который получает ссылку на одно свойство (новое состояние), и интерфейс Observer должен иметь основные методы, которые нужны для изменения, подписки и получения нашего состояния.

Основные компоненты кастомного Observer (рисунок 1) выглядят следующим образом: 1) метод getState() просто возвращает наше состояние; 2) метод mutate() изменяет наше состояние, а затем запускает notify(), чтобы уведомить всех зарегистрированных подписчиков и инициировать их обратные вызовы с передачей нового состояния; 3) метод subscribe() регистрирует новых подписчиков и обратные вызовы для отслеживания изменений состояния.

Рисунок 1. Реализация наблюдателя состояния

Поставщик ObserverProvider (рисунок 2) будет передавать экземпляр класса наблюдателя всем подкомпонентам – этот провайдер принимает свойство initialState для инициализации начального состояния внутри поставщика, которое будет передано в Observer.

Рисунок 2. Настройка поставщика наблюдателя состояния

Экземпляр наблюдателя использует здесь хук useRef, чтобы избежать любого эффекта со стороны реактивности системы React – useRef не уведомляет компонент об изменении своего значения, и это не вызывает повторной отрисовки, даже если значение ref изменилось.

Хук изменения состояния useMutate работает как функция-установщик значения нового состояния – он получает экземпляр наблюдателя от провайдера и использует метод mutate для отправки нового измененного состояния наблюдателю, а тот уже рассылает его подписчикам. Стоит заметить, что в данном хуке мы обернули стрелочную функцию с помощью другого хука useCallback, чтобы избежать нового создания данной функции каждый раз, когда подключенный компонент повторно отрисовывается.

Хук выборки данных useSelector работает как механизм синхронизации состояния наблюдателя с локальным состоянием данного хука, и это дает возможность взаимодействовать с подключенными компонентами React (рисунок 3).

Рисунок 3. Использование наблюдателя состояния в приложении

Таким образом, если попытаться исследовать самые популярные инструменты управления состоянием в React, можно увидеть, что их основная конструкция сосредоточена вокруг рассмотренного шаблона проектирования, также некоторые инструменты имеют расширенные функции, такие как редукторы для управления сложных изменений.

Список литературы:

1. Context [Электронный ресурс] URL: https://reactjs.org/docs/context.html (дата обращения: 17.12.2022).
2. Redux [Электронный ресурс] URL: https://redux.js.org (дата обращения: 17.12.2022).
3. Recoil [Электронный ресурс] URL: https://recoiljs.org (дата обращения: 17.12.2022).
4. Берьянов М.С. Построение React веб-приложения на основе шаблона проектирования издатель-подписчик // Студенческий - 2022. - № 40-1 (210). - С. 48-50.