Очередь обновлений состояния в React

Содержание туториала по React Установка переменной состояния поставит в очередь следующий рендеринг. Но иногда нужно выполнить несколько операций над значением перед постановкой в очередь следующего рендеринга. Для этого полезно понять, как React пакетно обновляет состояние (батчинг).

React батчит обновления состояний

Батчинг - это объединение обновлений в одну операцию. В следующем примере, вы можете ожидать, что нажатие кнопки «+3» увеличит счетчик три раза, потому что он трижды вызывает setNumber(number + 1):

import { useState } from 'react';

export default function Counter() {
  const [number, setNumber] = useState(0);

  return (
    <>
      <h1>{number}</h1>
      <button
        onClick={() => {
          setNumber(number + 1);
          setNumber(number + 1);
          setNumber(number + 1);
        }}
      >
        +3
      </button>
    </>
  );
}

Однако, как вы, возможно, помните из предыдущего раздела, значения состояния каждого рендеринга фиксированы, поэтому значение number внутри обработчика событий первого рендеринга всегда равно 0, независимо от того, сколько раз вы вызываете setNumber(1):

setNumber(0 + 1);
setNumber(0 + 1);
setNumber(0 + 1);

Но здесь есть еще один фактор, который нужно обсудить. React ждет, пока весь код в обработчиках событий будет запущен, прежде чем обрабатывать ваши обновления состояния. Вот почему повторный рендеринг происходит только после всех этих вызовов setNumber(). Это может напомнить вам официанта, принимающего заказ в ресторане. Официант не бежит на кухню при упоминании вашего первого блюда. Вместо этого они позволяют вам закончить свой заказ, позволяют вносить в него изменения и даже принимать заказы от других людей за столом. Это позволяет вам обновлять несколько переменных состояния — даже из нескольких компонентов — без запуска слишком большого количества повторных рендерингов. Но это также означает, что пользовательский интерфейс не будет обновляться до тех пор, пока ваш обработчик событий и любой код в нем не завершится. Такое поведение, также известное как пакетная обработка (батчинг), позволяет вашему приложению React работать намного быстрее. Это также позволяет избежать сбивающих с толку «недоделанных» рендеров, в которых были обновлены только некоторые переменные. React не объединяет несколько преднамеренных событий, таких как клики, — каждый клик обрабатывается отдельно. Будьте уверены, что React выполняет пакетную обработку только тогда, когда это в целом безопасно. Это гарантирует, что, например, если первый клик кнопки отключит форму, второй щелчок не отправит ее снова.

Обновление одной и той же переменной состояния несколько раз перед следующим рендерингом

Это необычный вариант использования, но если вы хотите обновить одну и ту же переменную состояния несколько раз перед следующим рендерингом, вместо передачи следующего значения состояния, такого как setNumber(number + 1), вы можете передать функцию, которая вычисляет следующее состояние. на основе предыдущего в очереди, например setNumber(n => n + 1). Это способ сказать React «сделать что-нибудь со значением состояния», а не просто заменить его. Вот как это выглядит на практике:

import { useState } from 'react';

export default function Counter() {
  const [number, setNumber] = useState(0);

  return (
    <>
      <h1>{number}</h1>
      <button
        onClick={() => {
          setNumber((n) => n + 1);
          setNumber((n) => n + 1);
          setNumber((n) => n + 1);
        }}
      >
        +3
      </button>
    </>
  );
}

Здесь n => n + 1 называется функцией обновления. Когда вы передаете его установщику состояния:

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

setNumber((n) => n + 1);
setNumber((n) => n + 1);
setNumber((n) => n + 1);

Вот как React работает с этими строками кода при выполнении обработчика событий:

1. setNumber(n => n + 1): n => n + 1 — это функция. React добавляет его в очередь.
2. setNumber(n => n + 1): n => n + 1 — это функция. React добавляет его в очередь.
3. setNumber(n => n + 1): n => n + 1 — это функция. React добавляет его в очередь.

Когда вы вызываете useState во время следующего рендеринга, React проходит через очередь. Предыдущее числовое состояние было 0, так что это то, что React передает первой функции обновления в качестве аргумента n. Затем React берет возвращаемое значение вашей предыдущей функции обновления и передает его следующему обновлению как n и так далее:

запланированное обновление	n	возвращает
n => n + 1	0	0 + 1 = 1
n => n + 1	1	1 + 1 = 2
n => n + 1	2	2 + 1 = 3

React сохраняет 3 в качестве конечного результата и возвращает его из useState. Вот почему нажатие «+3» в приведенном выше примере корректно увеличивает значение на 3.

Что произойдет, если вы обновите состояние после его замены

А как насчет этого обработчика событий? Как вы думаете, какое число будет в следующем рендере?

<button onClick={() => {
  setNumber(number + 5);
  setNumber(n => n + 1);
}}>

import { useState } from 'react';

export default function Counter() {
  const [number, setNumber] = useState(0);

  return (
    <>
      <h1>{number}</h1>
      <button
        onClick={() => {
          setNumber(number + 5);
          setNumber((n) => n + 1);
        }}
      >
        Increase the number
      </button>
    </>
  );
}

Вот что этот обработчик событий говорит React:

1. setNumber(number + 5): number равно 0, поэтому получаем setNumber(0 + 5). React добавляет в свою очередь «заменить на 5».
2. setNumber(n => n + 1): n => n + 1 — это функция обновления. React добавляет эту функцию в свою очередь.

Во время следующего рендера React проходит через очередь состояний:

запланированное обновление	n	возвращает
"заменить на 5"	0 (не используется)	5
n => n + 1	5	5 + 1 = 6

React сохраняет 6 в качестве конечного результата и возвращает его из useState. Вы могли заметить, что setState(x) на самом деле работает как setState(n => x), но n не используется.

Что произойдет, если вы замените состояние после его обновления

Давайте попробуем еще один пример. Как вы думаете, какое число будет в следующем рендере?

<button onClick={() => {
  setNumber(number + 5);
  setNumber(n => n + 1);
  setNumber(42);
}}>

import { useState } from 'react';

export default function Counter() {
  const [number, setNumber] = useState(0);

  return (
    <>
      <h1>{number}</h1>
      <button
        onClick={() => {
          setNumber(number + 5);
          setNumber((n) => n + 1);
          setNumber(42);
        }}
      >
        Increase the number
      </button>
    </>
  );
}

Вот как React работает с этими строками кода при выполнении этого обработчика событий:

1. setNumber(number + 5): number равно 0, поэтому setNumber(0 + 5). React добавляет в свою очередь «заменить на 5».
2. setNumber(n => n + 1): n => n + 1 — это функция обновления. React добавляет эту функцию в свою очередь.
3. setNumber(42): React добавляет в свою очередь «заменить на 42». Во время следующего рендера React проходит через очередь состояний:

запланированное обновление	n	возвращает
"заменить на 5"	0 (не используется)	5
n => n + 1	5	5 + 1 = 6
"заменить на 42"	6 (не используется)	42

Затем React сохраняет 42 как окончательный результат и возвращает его из useState. Подводя итог, вот как вы можете думать о том, что вы передаете установщику состояния setNumber:

• Функция обновления (например, n => n + 1) добавляется в очередь.
• Любое другое значение (например, число 5) добавляет в очередь «заменить на 5», игнорируя то, что уже находится в очереди.

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

Соглашения об именах

Аргумент функции обновления принято называть первыми буквами соответствующей переменной состояния:

setEnabled((e) => !e);
setLastName((ln) => ln.reverse());
setFriendCount((fc) => fc * 2);

Если вы предпочитаете более подробный код, другим распространенным соглашением является повторение полного имени переменной состояния, например setEnabled(enabled => !enabled), или использование префикса, такого как setEnabled(prevEnabled => !prevEnabled).

Резюме

• Установка состояния не изменяет переменную в существующем рендеринге, но запрашивает новый рендеринг.
• React обрабатывает обновления состояния после завершения работы обработчиков событий. Это называется батчингом.
• Чтобы обновить некоторое состояние несколько раз в одном событии, вы можете использовать функцию обновления setNumber(n => n + 1).

В первой части мы говорили о настройке маршрутизатора и упоминали BrowserRouter и NativeRouter, но это не единственные типы роутеров. Всего существует 6 роутеров, и в этой части мы подробно рассмотрим каждый из них. Серия статей о React Router v6 состоит из 4 частей.

1. Основы React Router
2. Продвинутые определения маршрутов
3. Управление навигацией
4. Подробно о роутерах (рассматривается в этой статье)

BrowserRouter

Из первой части мы уже знакомы с BrowserRouter. Это роутер по умолчанию, который вы должны использовать, если вы работаете над веб-приложением, и это роутер, который вы будете использовать в 99% всех своих приложений, поскольку он охватывает все обычные варианты использования маршрутизации. Другие роутеры, о которых поговорим далее, имеют очень специфические варианты использования.

NativeRouter

NativeRouter по сути является эквивалентом BrowserRouter, но для React Native. Если вы используете React Native, то это роутер, который вы захотите использовать.

HashRouter

Этот роутер работает очень похоже на BrowserRouter, но основное отличие заключается в том, что вместо того, чтобы изменять URL-адрес на что-то вроде http://localhost:3000/books он будет хранить URL-адрес в хэше, как http://localhost:3000/#/books. Как видите, этот URL-адрес имеет # после URL-адреса, который представляет собой хэш-часть URL-адреса. Все, что находится в хэш-части URL-адреса, является просто дополнительной информацией, которая обычно обозначает идентификатор на странице для целей прокрутки, поскольку страница будет автоматически прокручиваться до элемента с идентификатором, представленным хешем, при загрузке страницы. В React Router этот хэш на самом деле не используется для хранения идентификационной информации для прокрутки, а вместо этого он хранит информацию, связанную с текущим URL-адресом. Причина, по которой React Router делает это, заключается в том, что некоторые хостинг-провайдеры не позволяют вам фактически изменять URL-адрес вашей страницы. В этих очень редких случаях вы захотите использовать HashRouter, поскольку HashRouter не изменит фактический URL-адрес вашей страницы, а изменит только хэш вашей страницы. Если вы можете использовать какой-либо URL-адрес у своего хостинг-провайдера, то это не то, что вам следует использовать.

HistoryRouter

HistoryRouter (в настоящее время называется unstable_HistoryRouter) — это роутер, который позволяет вручную управлять объектом истории, который React Router использует для хранения всей информации, связанной с историей маршрутизации вашего приложения. Этот объект истории помогает убедиться, что такие вещи, как кнопки «Назад» и «Вперед» в браузере, работают правильно. Это роутер, который вы, вероятно, никогда не должны использовать, если у вас нет очень конкретной причины, по которой вы хотите перезаписать или контролировать поведение истории по умолчанию React Router.

MemoryRouter

MemoryRouter немного отличается от остальных роутеров, о которых мы говорили, поскольку вместо того, чтобы хранить информацию о текущем маршруте в URL-адресе браузера, этот роутер хранит информацию о роуте непосредственно в памяти. Очевидно, что это очень неподходящий роутер для обычных операций маршрутизации, но этот роутер невероятно полезен, когда вы пишете тесты для своего приложения, у которого нет доступа к браузеру. Из-за того, как работает React Router, вам необходимо, чтобы ваши компоненты были упакованы в маршрутизатор, иначе весь ваш код маршрутизации будет выдавать ошибки и ломаться. Это означает, что даже если вы хотите протестировать один компонент, вам нужно будет обернуть этот компонент внутрь маршрутизатора, иначе он будет выдавать ошибки. Если вы тестируете свой код таким образом, что у него нет доступа к браузеру (например, модульное тестирование), то маршрутизаторы, о которых мы говорили до сих пор, будут выдавать ошибки, поскольку все они зависят от URL-адреса в браузере. MemoryRouter, с другой стороны, хранит всю свою информацию в памяти, что означает, что он никогда не обращается к браузеру и идеально подходит при модульном тестировании компонентов. Однако, за исключением этого конкретного случая использования, этот маршрутизатор никогда не будет использоваться.

StaticRouter

Роутер StaticRouter также имеет очень специфический вариант использования. Этот маршрутизатор специально предназначен для серверного рендеринга ваших приложений React, поскольку он принимает один проп location и визуализирует ваше приложение, используя этот location в качестве URL-адреса. Этот роутер на самом деле не может выполнять какую-либо маршрутизацию и будет просто отображать одну статическую страницу, но это идеально подходит для рендеринга на сервере, поскольку вы хотите просто отобразить HTML вашего приложения на сервере, а затем клиент может настроить всю вашу маршрутизацию и так далее.

<StaticRouter location="/books">
  <App />
</StaticRouter>

Итоги

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