> Какие аргументы принимает setState с функцией обратного вызова в React (React, TypeScript)

Короткий ответ

setState с функцией обратного вызова принимает два аргумента: updater-функцию вида (prevState, props) => partialState и опциональный callback, который выполнится после применения обновления. Updater получает предыдущее состояние и props на момент вызова, что гарантирует корректную работу при асинхронных обновлениях. Это особенно важно при множественных вызовах setState в одном цикле рендера.

Подробное объяснение

Функциональная форма setState решает проблему гонки состояний при асинхронных обновлениях. React может батчить (группировать) несколько вызовов setState в один цикл рендера, и при использовании объектной формы setState({ count: this.state.count + 1 }) каждый вызов будет опираться на одно и то же состояние, что приводит к потере обновлений.

Updater-функция гарантирует, что каждый вызов получает актуальное предыдущее состояние, независимо от того, сколько раз setState был вызван до применения изменений. Тип функции: (prevState: S, props: P) => Partial<S> | null. Возврат null означает, что обновление не требуется.

Второй аргумент - callback, который вызывается после того, как состояние было обновлено и компонент перерендерен. Это аналог componentDidUpdate для конкретного обновления, но в классовых компонентах. В функциональных компонентах с хуками эту роль выполняет useEffect с зависимостями.

Важно: setState с функцией не делает глубокое слияние (shallow merge) - он заменяет указанные поля, но не объединяет их с предыдущим состоянием рекурсивно. Это поведение идентично объектной форме.

На практике

В реальных проектах функциональная форма setState используется:

• при инкрементах и декрементах, где новое состояние зависит от предыдущего
• при работе с очередями обновлений в анимациях или играх
• когда нужно гарантировать атомарность изменений в условиях конкурентных запросов

Callback-аргумент применяется редко, так как обычно достаточно componentDidUpdate или эффектов. Однако он полезен для логирования или синхронных действий после обновления, когда нужно избежать лишнего рендера.

В TypeScript типизация выглядит так:

TYPESCRIPT
setState<K extends keyof S>(
  state: ((prevState: Readonly<S>, props: Readonly<P>) => Pick<S, K> | S | null),
  callback?: () => void
): void

Пример кода

TYPESCRIPT
// Проблема: объектная форма теряет обновления
this.setState({ count: this.state.count + 1 });
this.setState({ count: this.state.count + 1 }); // count увеличится только на 1

// Решение: функциональная форма
this.setState((prevState) => ({ count: prevState.count + 1 }));
this.setState((prevState) => ({ count: prevState.count + 1 })); // count увеличится на 2

// С callback для пост-обработки
this.setState(
  (prevState) => ({ items: [...prevState.items, newItem] }),
  () => console.log('State updated, items count:', this.state.items.length)
);

Как отвечать на собеседовании

Начни с чёткого определения: два аргумента - updater и callback. Объясни, почему функциональная форма важна для асинхронных обновлений и батчинга. Приведи пример с инкрементом, где объектная форма даёт неверный результат. Упомяни, что callback - это устаревший паттерн, и в современных React-приложениях с хуками его заменяют эффекты.

Покажи понимание типов TypeScript, особенно Readonly<S> и Pick<S, K>. Отметь, что prevState - это не мутированный объект, а снимок состояния на момент вызова updater. Если спросят про производительность - скажи, что функциональная форма не медленнее объектной, а в некоторых случаях даже быстрее за счёт устранения лишних слияний.

Что проверяет интервьюер

• Понимание асинхронной природы setState и батчинга в React
• Знание разницы между объектной и функциональной формами
• Умение объяснить, почему функциональная форма решает проблему гонки состояний
• Владение TypeScript-типизацией для setState
• Понимание, когда нужен callback и как его заменить в функциональных компонентах

Типичные ошибки

• Утверждение, что функциональная форма всегда предпочтительнее - на самом деле, если новое состояние не зависит от предыдущего, объектная форма короче и читаемее
• Забывание, что prevState - это Readonly, и попытка его мутировать
• Использование callback для сложной логики, которую лучше вынести в componentDidUpdate или useEffect
• Путаница между setState в классовых и функциональных компонентах (в хуках нет аналога с callback)
• Непонимание, что функциональная форма не делает глубокое слияние, а только поверхностное