В этой статье мы рассмотрим использование ReactDOM.unstable_batchedUpdates в тестовом примере, в частности, в Zustand, популярной библиотеке управления состоянием для React. Мы также разберем тест и объясним, как пакетные обновления повышают производительность React за счет минимизации ненужных повторных рендерингов.

Понимание тестового примера

Вот тестовый пример, который мы будем изучать:

Этот тестовый пример написан для проверки возможности применения пакетных обновлений при использовании Zustand с системой рендеринга React.

Разбор тестового примера

1. Настройка магазина Zustand: Первый шаг включает создание магазина Zustand с помощью функции создания:

const useBoundStore = create(
  (set) => ({   
  count: 0,   
  inc: () => set((state) => ({ count: state.count   1 })), }))

Здесь хранилище поддерживает простое состояние со свойством count, инициализированным значением 0, и функцией inc для увеличения счетчика. Функция set — это способ обновления состояния в Zustand, аналогичный setState в React.

2. Компонент Counter: Компонент Counter использует useBoundStore для получения текущего счетчика и функции inc:

const { count, inc } = useBoundStore()

Этот компонент подписывается на состояние хранилища, и любые изменения в подсчете приведут к его повторному рендерингу с новым значением.

3. Использование ReactDOM.unstable_batchedUpdates для повышения производительности: Внутри хука useEffect функция inc вызывается дважды внутри блока ReactDOM.unstable_batchedUpdates:

useEffect(() => {   
  ReactDOM.unstable_batchedUpdates(() => {     
    inc()     
    inc()   
  }) 
}, [inc])

Здесь происходит волшебство. Обычно каждый вызов inc() вызывает отдельное обновление, вызывающее два рендеринга. Однако, обернув эти вызовы в нестабильный_batchedUpdates, React сможет обработать их вместе в одном обновлении, в результате чего будет выполнен только один рендеринг. Это оптимизирует производительность за счет сокращения количества рендерингов, что особенно полезно в приложениях, где производительность критична.

4. Рендеринг компонента и подтверждение результата Наконец, компонент визуализируется, и тест ожидает, пока счетчик достигнет 2:

const { findByText } = render(
       
    >, 
)  

await findByText('count: 2')

Это утверждение гарантирует, что после двух приращений счетчик корректно обновляется и отображается как «count: 2».

Что такое ReactDOM.unstable_batchedUpdates?

ReactDOM.unstable_batchedUpdates — это метод, предоставляемый React, который позволяет обрабатывать несколько обновлений состояния за один цикл рендеринга. По умолчанию React группирует обновления, запускаемые внутри обработчиков событий (например, события щелчка), а это означает, что если вы обновляете несколько состояний в ответ на взаимодействие с пользователем, React будет отображать компонент только один раз. Однако за пределами обработчиков событий (например, в setTimeout или useEffect) обновления не группируются автоматически.

Но после React 18 ситуация изменилась. Ниже приведены скриншоты, взятые с сайта act.dev

Имейте в виду, что документация предполагает, что обновления внутри таймаутов, обещаний, собственных обработчиков событий или любых других событий будут пакетироваться так же, как обновления внутри событий React. Но в этом тестовом примере Зустанда пакетные обновления применяются внутри useEffect`. Вот тут-то и становится полезным нестабильный_batchedUpdates. Это заставляет React группировать несколько обновлений состояния в один рендеринг, даже вне контекстов, управляемых событиями, сводя к минимуму повторные рендеринги и повышая производительность.

Пример:

Без нестабильных_батчедобновлений:

inc()  // triggers one render
inc()  // triggers another render

С нестабильными обновлениями:

ReactDOM.unstable_batchedUpdates(() => {
  inc()  // triggers only one render for both updates
  inc()
})

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

Интересный факт: в выпуске Zustand 4.5.5 используется версия 19.0.0-rc.0

Зачем использовать ReactDOM.unstable_batchedUpdates в Zustand?

Zustand — это легкая библиотека управления состоянием, которая работает с жизненным циклом компонентов React. Хотя Zustand эффективно обрабатывает обновления состояния, система реактивности React запускает рендеринг каждый раз, когда состояние изменяется. В сценариях, когда за короткий период происходит несколько изменений состояния, использование ReactDOM.unstable_batchedUpdates может предотвратить множественные повторные рендеринги и пакетировать обновления, обеспечивая более плавное и эффективное взаимодействие с пользователем.

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

О нас:

В Think Throo мы стремимся обучать передовым архитектурным концепциям кодовой базы, используемым в проектах с открытым исходным кодом.

Увеличьте свои навыки программирования в 10 раз, практикуя передовые архитектурные концепции в Next.js/React, изучайте лучшие практики и создавайте проекты промышленного уровня.

У нас открытый исходный код — https://github.com/thinkthroo/thinkthroo (дайте нам звезду!)

Повышайте квалификацию своей команды с помощью наших продвинутых курсов, основанных на архитектуре кодовой базы. Чтобы узнать больше, напишите нам по адресу [email protected]!

Ссылки:

1. https://github.com/pmndrs/zustand/blob/v4.5.5/tests/basic.test.tsx#L175C7-L175C39

2. https://dev.to/devmoustafa97/do-you-know-unstablebatchedupdates-in-react-enforce-batching-state-update-5cn2

3. https://dev.to/jackbuchananconroy/react-18-what-s-changed-automatic-batching-13ec

4. https://react.dev/blog/2022/03/08/react-18-upgrade-guide#automatic-batching

5. https://github.com/pmndrs/zustand/blob/v4.5.5/package.json#L246C4-L247C32