С какими менеджерами состояния форм ты работал
Что проверяют
Понимаете ли вы, что состояние формы локальное и временное, и умеете ли выбирать библиотеку по цене перерисовок, а не по популярности. Заодно проверяют, доводили ли вы форму до боевого вида: серверные ошибки, динамические поля, чужие компоненты.
Как отвечать
Начните с разделения подходов, а не с названий.
- Контролируемая форма: значение живёт в состоянии React, каждое нажатие клавиши перерисовывает компонент. Так работает Formik, и на большой форме это заметно.
- Неконтролируемая: значения хранит сам DOM, библиотека подписывается на поля и обновляет только то, что нужно. Так устроен React Hook Form, поэтому его обычно и берут по умолчанию.
Дальше про то, что реально решаете: схема валидации на zod или yup подключается резолвером, режим проверки выбирается осознанно (onBlur для длинных форм, onSubmit для коротких), ответ сервера раскладывается по полям через setError, массивы полей через useFieldArray, компоненты из UI-библиотеки оборачиваются в Controller.
Полезно сказать, что глобальное хранилище под форму вы не заводите: черновик переживает уход со страницы только когда это отдельное требование, и тогда достаточно сохранить значения в браузере. Если работали с Final Form, TanStack Form или нативной формой на FormData, назовите и их.
Где спотыкаются
Называют Redux менеджером состояния форм. Redux это общее хранилище приложения, а redux-form давно заброшен, его же автор увёл пользователей на другую библиотеку. Ответ про глобальный стор для полей ввода читается как рассказ о давнем проекте.
Второе: валидация только на клиенте. Схема на фронте это удобство для пользователя, а правда живёт на сервере, и его ответ надо уметь разложить по конкретным полям, а не показать одним красным баннером над формой.
Третье: в React Hook Form подписываются на всю форму через watch прямо в теле компонента и получают перерисовку на каждое нажатие, ради избавления от которой библиотеку и выбирали. Для точечной подписки есть useWatch.