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

9 месяцев назад·6 мин. на чтение

Установка переменной состояния поставит в очередь следующий рендеринг. Но иногда нужно выполнить несколько операций над значением перед постановкой в очередь следующего рендеринга. Для этого полезно понять, как 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 + 100 + 1 = 1
n => n + 111 + 1 = 2
n => n + 122 + 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 + 155 + 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 + 155 + 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).

Состояние как снимок в React

9 месяцев назад·5 мин. на чтение

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

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

Установка состояния запускает рендеринг

Вы можете думать о своем пользовательском интерфейсе как об изменении непосредственно в ответ на пользовательское событие, такое как клик. В React это работает немного иначе, чем эта ментальная модель. На предыдущей странице вы видели, что изменение состояния запрашивает повторный рендеринг. Это означает, что для того, чтобы интерфейс отреагировал на событие, вам необходимо обновить состояние. В этом примере, когда вы нажимаете "send", setIsSent(true) сообщает React повторно отобразить пользовательский интерфейс:
import { useState } from 'react';

export default function Form() {
  const [isSent, setIsSent] = useState(false);
  const [message, setMessage] = useState('Hi!');
  if (isSent) {
    return <h1>Your message is on its way!</h1>;
  }
  return (
    <form
      onSubmit={(e) => {
        e.preventDefault();
        setIsSent(true);
        sendMessage(message);
      }}
    >
      <textarea
        placeholder="Message"
        value={message}
        onChange={(e) => setMessage(e.target.value)}
      />
      <button type="submit">Send</button>
    </form>
  );
}

function sendMessage(message) {
  // ...
}
Вот что происходит, когда вы нажимаете кнопку:
  1. Выполняется обработчик события onSubmit.
  2. setIsSent(true) устанавливает isSent в true и кладет в очередь новый рендеринг.
  3. React повторно отображает компонент в соответствии с новым значением isSent.
Давайте подробнее рассмотрим взаимосвязь между состоянием и рендерингом.

Рендеринг делает снимок во времени

"Рендеринг" означает, что React вызывает ваш компонент, который является функцией. JSX, который вы возвращаете из этой функции, подобен снимку пользовательского интерфейса в момент времени. Его пропсы, обработчики событий и локальные переменные были рассчитаны с использованием его состояния во время рендеринга. В отличие от фотографии или кадра фильма, "снимок" пользовательского интерфейса, который вы возвращаете, является интерактивным. Он включает в себя логику, такую ​​как обработчики событий, которые определяют, что происходит в ответ на входные данные. Затем React обновляет экран в соответствии с этим снимком и подключает обработчики событий. В результате нажатие кнопки вызовет обработчик кликов из вашего JSX. Когда React перерисовывает компонент:
  1. React снова вызывает вашу функцию.
  2. Ваша функция возвращает новый снимок JSX.
  3. Затем React обновляет экран в соответствии со снимком, который вы вернули.
Состояние, как память компонента, не похоже на обычную переменную, которая исчезает после возврата из вашей функции. Состояние на самом деле «живет» в самом React — как будто на полке! — вне вашей функции. Когда React вызывает ваш компонент, он дает вам снимок состояния для этого конкретного рендеринга. Ваш компонент возвращает снимок пользовательского интерфейса со свежим набором пропсов и обработчиков событий в своем JSX, и все они рассчитаны с использованием значений состояния из этого рендеринга.
Вот небольшой эксперимент, чтобы показать вам, как это работает. В этом примере вы можете ожидать, что нажатие кнопки «+3» увеличит счетчик на три, потому что он вызывается setNumber(number + 1) три раза. Посмотрите, что происходит, когда вы нажимаете кнопку «+3»:
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 увеличивается только один раз за клик! Установка состояния изменяет его только для следующего рендера. Во время первого рендера number было 0. Вот почему в обработчике этого рендеринга onClick значение number по-прежнему остается 0 даже после вызова setNumber(number + 1):
<button
  onClick={() => {
    setNumber(number + 1);
    setNumber(number + 1);
    setNumber(number + 1);
  }}
>
  +3
</button>
Вот что обработчик нажатия этой кнопки сообщает React:
  1. setNumber(number + 1): number равно 0 таким образом setNumber(0 + 1).
    • React готовится изменить number на 1 в следующем рендеринге.
  2. setNumber(number + 1): number равно 0 таким образом setNumber(0 + 1).
    • React готовится изменить number на 1 в следующем рендеринге.
  3. setNumber(number + 1): number равно 0 таким образом setNumber(0 + 1).
    • React готовится изменить number на 1 в следующем рендеринге.
Несмотря на то, что вы вызвали setNumber(number + 1) три раза, в этом рендере обработчик событий number всегда равен 0, поэтому вы устанавливаете состояние 1 три раза. Вот почему после завершения обработчика событий React повторно отображает компонент с number равным 1, а не 3. Вы также можете визуализировать это, мысленно заменяя переменные состояния их значениями в своем коде. Поскольку number переменная состояния равна 0 для этого рендера, его обработчик событий выглядит так:
<button
  onClick={() => {
    setNumber(0 + 1);
    setNumber(0 + 1);
    setNumber(0 + 1);
  }}
>
  +3
</button>
Для следующего рендера number равен 1, так что обработчик клика этого рендера выглядит так:
<button
  onClick={() => {
    setNumber(1 + 1);
    setNumber(1 + 1);
    setNumber(1 + 1);
  }}
>
  +3
</button>
Вот почему повторное нажатие на кнопку установит счетчик на 2, затем 3 на следующий клик и т.д.

Состояние с течением времени

Попробуйте угадать, какое сообщение будет выведено в alert при нажатии этой кнопки:
import { useState } from 'react';

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

  return (
    <>
      <h1>{number}</h1>
      <button
        onClick={() => {
          setNumber(number + 5);
          alert(number);
        }}
      >
        +5
      </button>
    </>
  );
}
Если вы используете метод замены из предыдущего, вы можете догадаться, что предупреждение покажет 0:
setNumber(0 + 5);
alert(0);
Но что, если положите alert в таймер, чтобы оно срабатывало только после повторного рендеринга компонента? Будет ли он показывать 0 или 5?
import { useState } from 'react';

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

  return (
    <>
      <h1>{number}</h1>
      <button
        onClick={() => {
          setNumber(number + 5);
          setTimeout(() => {
            alert(number);
          }, 3000);
        }}
      >
        +5
      </button>
    </>
  );
}
Если вы используете метод подстановки, вы можете увидеть «снимок» состояния, переданного в alert.
setNumber(0 + 5);
setTimeout(() => {
  alert(0);
}, 3000);
Состояние, хранящееся в React, могло измениться к моменту запуска оповещения, но оно было запланировано с использованием снимка состояния на момент взаимодействия с ним пользователя. Значение переменной состояния никогда не изменяется в процессе рендеринга, даже если код обработчика событий является асинхронным. Внутри onClick этого рендера значение number продолжает оставаться 0 даже после вызова setNumber(number + 5). Его значение было «фиксировано», когда React «сделал снимок» пользовательского интерфейса, вызвав ваш компонент.
Вот пример того, как это делает ваши обработчики событий менее подверженными ошибкам синхронизации. Ниже представлена ​​форма, которая отправляет сообщение с пятисекундной задержкой. Представьте себе этот сценарий:
  1. Вы нажимаете кнопку «Отправить», отправляя «Привет» Алисе.
  2. Прежде чем закончится пятисекундная задержка, вы измените значение поля «Кому» на «Боб».
Что будет выведено в alert? Будет ли он отображать «Вы поздоровались с Алисой»? Или он будет отображать «Вы поздоровались с Бобом»? Сделайте предположение, основанное на том, что вы знаете:
import { useState } from 'react';

export default function Form() {
  const [to, setTo] = useState('Alice');
  const [message, setMessage] = useState('Hello');

  function handleSubmit(e) {
    e.preventDefault();
    setTimeout(() => {
      alert(`You said ${message} to ${to}`);
    }, 5000);
  }

  return (
    <form onSubmit={handleSubmit}>
      <label>
        To:{' '}
        <select value={to} onChange={(e) => setTo(e.target.value)}>
          <option value="Alice">Alice</option>
          <option value="Bob">Bob</option>
        </select>
      </label>
      <textarea
        placeholder="Message"
        value={message}
        onChange={(e) => setMessage(e.target.value)}
      />
      <button type="submit">Send</button>
    </form>
  );
}
React сохраняет значения состояния «фиксированными» в обработчиках событий одного рендеринга. Вам не нужно беспокоиться о том, изменилось ли состояние во время выполнения кода. Но что, если вы хотите прочитать последнее состояние перед повторным рендерингом? Вы захотите использовать функцию обновления состояния, описанную на следующей странице.

Резюме

  • Состояние установки запрашивает новый рендеринг.
  • React хранит состояние вне вашего компонента, как на полке.
  • Когда вы вызываете useState, React дает вам снимок состояния для этого рендеринга .
  • Переменные и обработчики событий не «выживают» при повторном рендеринге. Каждый рендер имеет свои обработчики событий.
  • Каждый рендер (и функции внутри него) всегда будет «видеть» снимок состояния, которое React дал этому рендеру.
  • Вы можете мысленно заменить состояние в обработчиках событий, подобно тому, как вы думаете об отрендеренном JSX.
  • Обработчики событий, созданные в прошлом, имеют значения состояния из рендеринга, в котором они были созданы.