React form libraries для бизнес-форм без хаоса

Почему формы превращаются в спагетти

Одна форма редко остаётся маленькой. Команда начинает с шести полей, одной кнопки отправки и пары проверок. Через два месяца на том же экране уже 40 полей, условные блоки, скрытые шаги и правила, которые зависят от тарифа, роли пользователя, страны или статуса договора.

Такой рост быстро превращает код в хаос, потому что правила не остаются в одном месте. Один разработчик добавляет обязательную проверку прямо в компонент поля. Другой пишет helper для логики с датами. Команда бэкенда отклоняет то же значение, но по немного другой причине. В итоге никто уже не понимает, какое правило на самом деле главное.

Обычно беспорядок появляется в нескольких местах:

• Состояние живёт в слишком большом числе компонентов, поэтому одно изменение вызывает ошибки в другом месте.
• Валидация копируется в UI-код, утилиты и обработчики API.
• Повторяющиеся строки, например контакты, адреса или позиции в счёте, становятся сложными, когда пользователи добавляют, удаляют или меняют их порядок.
• Текст ошибок перестаёт совпадать с реальным бизнес-правилом, и пользователи исправляют не то.

Повторяющиеся поля усложняют всё сильнее, чем ожидает большинство команд. Один блок "контакт" кажется простым. Но десять контактов с вложенными телефонами, одним основным контактом и проверкой для каждой строки — это уже момент, когда простой код начинает ломаться. Перестановка строк может нарушить состояние touched, сопоставление ошибок или значения по умолчанию, если форма плохо работает с массивами.

Бизнес-экраны меняются ещё и во время разработки. Продажи просят добавить ещё одно исключение. Поддержка хочет скрытое поле для особых случаев. Юристы меняют формулировку согласия. Форма по-прежнему работает, но код превращается в набор разрозненных условий и разовых исправлений.

Именно поэтому команды вообще начинают сравнивать React form libraries. Им нужна не более красивая API. Им нужно одно понятное место для состояния, одно понятное место для правил и работа с массивами, которая не разваливается, когда экран начинает выглядеть как настоящий бизнес-продукт.

Библиотеки, которые действительно стоит сравнивать

Среди React form libraries только несколько названий постоянно всплывают на реальных бизнес-экранах. И это хороший знак. Команда может жить с инструментом для форм годами, поэтому скучное и надёжное обычно лучше, чем умное и новое.

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

• React Hook Form подходит многим CRUD-экранам, админ-панелям и сценариям онбординга. Он остаётся быстрым, хорошо работает со схемной валидацией и без особой драмы справляется с полями-массивами. Для многих команд это лучший баланс скорости, удобства и поддержки сообщества.
• Formik всё ещё встречается в старых приложениях, потому что многие команды взяли его рано и хорошо его знают. Он способен работать со сложными формами, но на больших экранах часто нужно больше связующего кода, а лишние перерисовки начинают раздражать. Если Formik уже используется в продакшене, чаще разумнее оставить его, чем бросаться в переписывание.
• TanStack Form даёт более точный контроль над состоянием формы и подписками. Это помогает, когда на большом экране много зависимых значений и обновляться должны только отдельные части. На старте он требует больше вдумчивости, но на сложных экранах этот контроль окупается.
• React Final Form остаётся компактным и сфокусированным. Он делает меньше, но делает это ясно. Команды, которым нужен лёгкий инструмент с предсказуемым поведением, всё ещё выбирают его, особенно если им не нужна большая экосистема дополнений.

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

Если вы делаете именно такие продуктовые экраны, которые стартапы и внутренние команды используют каждый день, React Hook Form обычно оказывается самым безопасным первым выбором. TanStack Form — сильный вариант, когда главная проблема в сложности состояния. Formik часто остаётся просто потому, что приложение уже на нём завязано. React Final Form по-прежнему остаётся хорошим компактным выбором. Риск обычно не в том, чтобы выбрать одну из этих библиотек. Риск — поставить на любительский инструмент, который через шесть месяцев никто не захочет распутывать.

Как состояние формы влияет на повседневную работу

Большинство React form libraries делают маленькое демо очень простым. Разница становится заметной, когда на реальном экране 40 полей, условные блоки, автосохранение и пользователь, который редактирует одну запись 20 минут.

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

Неконтролируемые поля выносят больше работы из состояния React. Обычно из-за этого большие формы ощущаются легче. Именно по этой причине стали популярны библиотеки вроде React Hook Form. Вы по-прежнему можете валидировать поля, отслеживать значения и отправлять чистые данные, но не платите ту же цену на каждом нажатии клавиши.

Экраны редактирования делают состояние формы гораздо важнее, чем формы с нуля. Создать новую запись проще, чем загрузить существующие данные, показать значения по умолчанию, сбросить форму после сохранения и предупредить пользователя о несохранённых изменениях. Здесь особенно важно отслеживание dirty state. Если библиотека не может легко ответить на вопрос "что изменилось?", команда начнёт писать свои проверки, и именно тут начинается беспорядок.

На повседневную работу сильнее всего влияют несколько вещей:

• Как задаются значения по умолчанию из данных API
• Как работает reset после сохранения или повторной загрузки
• Как обновляются поля dirty и touched
• Насколько легко смотреть состояние при отладке

DevTools тоже важны. Когда поле не обновляется, вы хотите сразу видеть текущие значения, ошибки, touched state и подписки. Хорошие типы TypeScript помогают не меньше. Они рано ловят неверные имена полей, что неожиданно сильно экономит время на вложенных объектах и массивах.

Маленькие демо скрывают эту боль, потому что обычно показывают пять полей и одну кнопку отправки. Настоящие бизнес-формы почти никогда не остаются такими маленькими. Многошаговый онбординг, редактор цен или профиль клиента с вложенными контактами быстро вскроют все слабые места состояния формы. Если библиотека остаётся удобной даже после двухсот полей и нескольких сбросов, скорее всего, в продакшене она тоже справится.

Схемная валидация без дублирования правил

Большинство ошибок в формах начинается там, где одно и то же правило живёт в трёх местах: в поле, в обработчике отправки и в API. Так простая форма клиента превращается в набор частных случаев.

Для базовых полей встроенных правил часто достаточно. Если имя обязательно или для телефона нужна минимальная длина, держите это рядом с полем и двигайтесь дальше. Не нужна целая схема только для того, чтобы сказать "это поле не может быть пустым".

React form libraries становятся чище, когда схемы используются для общих бизнес-правил, а не для каждой мелкой проверки. Формат налогового номера, правила адреса для выставления счёта или диапазон дат, который должен оставаться корректным сразу для нескольких полей, лучше держать в одной схеме. Это убирает дублирование и делает рефакторинг менее болезненным.

Выберите инструмент схем, который совпадает с вашим кодовой базой

Zod хорошо подходит для приложений, где много TypeScript. Он сближает типы и валидацию, что удобно, когда одна и та же структура данных проходит через форму, API-клиент и сервер. Если команда уже использует типизированные контракты, Zod обычно ощущается естественно.

Yup всё ещё встречается во многих существующих проектах, особенно в старых связках с Formik. Это не делает его плохим. Если команда знает Yup и формы уже завязаны на него, смена библиотеки может создать больше суеты, чем пользы.

Размещайте асинхронные проверки в одном понятном месте

Схема может проверить структуру и базовые бизнес-правила, но она не должна притворяться, что знает базу данных. Если email должен быть уникальным или номер компании должен совпадать с серверной записью, проверяйте это через понятный асинхронный путь. Держите такие правила рядом с отправкой формы или в отдельном async validator, чтобы всем было ясно, где живёт истина с сервера.

Условная логика всё равно требует вдумчивости. Одна схема не наведёт порядок в правилах вроде "просить VAT ID только для компаний из ЕС" или "запрашивать данные опекуна только если клиент младше 18". Кто-то всё равно должен чётко смоделировать условия, а UI должен показывать и скрывать поля так же, как этого ожидает валидатор.

Хорошая проверка простая: если правило меняется, может ли один разработчик обновить его в одном месте, не просматривая весь экран? Если нет, проблема не в библиотеке схем. Проблема в том, что правило размазано по коду.

Поля-массивы, на которых библиотеки показывают свои пределы

Бизнес-формы быстро становятся некрасивыми, когда на одном экране много повторяющихся строк. В счёте может быть несколько позиций, в карточке клиента — пять контактов, а в HR-форме — иждивенцы со своими данными. Вот тут React form libraries перестают казаться одинаковыми.

React Hook Form обычно справляется с этим лучше, потому что useFieldArray даёт каждой строке стабильный id. Это важнее, чем кажется. Если пользователь удаляет строку 2 или перетаскивает строки в новом порядке, ошибки должны оставаться у того же человека или той же позиции, а не прыгать на строку, которая теперь стоит на этом индексе.

Formik тоже может работать с массивами, но экраны с большим числом массивов часто ощущаются более хрупкими. Значительная часть логики оказывается привязана к индексам, и действия вроде изменения порядка или копирования строки быстро это вскрывают. TanStack Form гибок и продуман, но за это приходится платить сложностью настройки. На простой форме это не проблема. На вложенных массивах любая лишняя абстракция имеет цену.

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

Хорошая проверка для React form libraries простая:

• быстро добавить 10 строк
• переставить три строки местами
• продублировать одну строку вместе со значениями
• массово удалить выбранные строки
• сопоставить серверные ошибки с правильными полями

Именно последний пункт ломает многие в целом неплохие формы. Если сервер возвращает contacts[2].email как невалидный, UI должен надёжно показать ошибку в правильной строке. Если пользователь уже поменял порядок списка, логика на основе индексов может указывать не на тот контакт. Стабильные ids и понятное сопоставление путей экономят часы чистки.

Если на вашем экране есть массивы внутри массивов, выбирайте инструмент, который делает идентичность строки очевидной, а пути ошибок — скучными. Красивость API тут важна меньше. Когда пользователи редактируют 30 строк за один сеанс, скучность — это именно то, что вам нужно.

Реальный экран: онбординг клиента с множеством контактов

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

Теперь добавьте несколько реальных правил. Если клиент находится в Германии, запросите VAT data. Если тариф enterprise, потребуйте ответственного за согласование и данные по purchase order. Сотрудник отдела продаж может сохранить черновик, вернуться завтра и ожидать, что каждая строка, заметка и сообщение валидации по-прежнему будут иметь смысл.

Как каждая библиотека ощущается на таком экране

Formik справится с этим экраном, но быстро становится тяжёлым. Вложенные значения поначалу легко понимать, однако массивы контактов и адресов обычно приводят к большому количеству ручного связывания для touched state, ошибок и условной логики. Сохранение и восстановление черновиков работает, но большие формы часто перерисовываются чаще, чем хотелось бы, и это раздражает, когда сотрудники печатают длинные заметки или прыгают между повторяющимися строками.

React Hook Form обычно лучше подходит для такого случая. Он остаётся быстрым на больших экранах, потому что не все поля перерисовываются при каждом изменении. Поля-массивы — одна из его сильных сторон, поэтому добавить три контакта, удалить один адрес и сохранить остальные устойчивыми получается менее хрупко. Схемная валидация в React здесь тоже ощущается чище, потому что большую часть правил можно держать в одной схеме и менять их при смене страны или тарифа. Главная оговорка — работа с черновиками: нужно аккуратно обращаться с defaultValues, reset и контролируемыми компонентами вроде кастомных селектов.

TanStack Form делает сложные бизнес-правила более удобными для моделирования, а в некоторых случаях — более явными, чем React Hook Form. Если поля оплаты зависят от тарифа, а поля согласования зависят и от тарифа, и от страны, его состояние формы может ощущаться более предсказуемым. Но он требует больше настройки, и многие команды сначала будут двигаться медленнее, потому что мало кто знает его достаточно хорошо.

Для именно такого экрана React Hook Form часто оказывается самым безопасным выбором. Formik вполне подходит для маленьких команд, которые уже на нём сидят. TanStack Form — сильный вариант, когда форма больше похожа на небольшой workflow, чем на обычную страницу ввода данных.

Как выбирать библиотеку шаг за шагом

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

Если вы сравниваете React Hook Form vs Formik или TanStack Form, прогоните через все один и тот же неудобный экран. Честный тест лучше, чем чтение таблиц с возможностями. Бизнес-формы ломаются в скучных местах: логика сброса, частичное редактирование, скрытые поля, которые всё равно валидируются, и массивы, которые смещаются при добавлении или удалении строк.

1. Составьте список самых сложных экранов в приложении. Выберите тот, где смешаны простые поля, контакты, адреса, позиции в счёте или правила согласования.
2. Решите, где живёт валидация. Если команда уже использует библиотеку схем, держите правила там и не дублируйте те же проверки в компонентах полей.
3. Соберите одну настоящую форму редактирования. Включите поля-массивы, условные блоки, значения по умолчанию с сервера и одно-два вычисляемых поля.
4. Проверьте грязные сценарии. Сбросьте форму, сохраните черновик, перезагрузите данные с сервера и сопоставьте ошибки API с нужными полями.
5. Отложите форму на несколько дней. Потом вернитесь и прочитайте код как в первый раз. Если через неделю он уже кажется тесным, библиотека вам мешает.

Небольшой пример хорошо это показывает. Допустим, у вас есть экран онбординга клиента с профилем компании, тремя контактами, платёжными данными и дополнительным налоговым блоком, который появляется только для некоторых стран. Простое демо работает в любой библиотеке. Настоящая проверка начинается, когда пользователь удаляет второй контакт, восстанавливает черновик, а API возвращает ошибку для email третьего контакта.

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

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

Ошибки, которые превращают валидацию в спагетти

Команды редко делают грязную форму одним большим решением. Обычно всё начинается с маленьких сокращений. Одна обязательная проверка появляется прямо в поле, то же правило живёт в схеме, и через две недели уже никто не знает, какому правилу приложение вообще доверяет.

Поставьте границу заранее. Держите бизнес-правила в схеме, а маленькие UI-проверки — рядом с полем. Например, "email обязателен" и "дата начала должна быть раньше даты окончания" должны жить в одном общем месте. А "показывать ошибку после blur" относится к слою формы.

Ещё одна ошибка начинается с custom hook, который в первый день выглядит аккуратным. Вскоре этот hook прячет touched state, логику reset, асинхронную валидацию и зависимости между полями. Потом каждая ошибка превращается в поиск по слоям, которых вообще могло бы не быть. Держите состояние формы ближе к экрану, пока не увидите один и тот же паттерн несколько раз.

Команды также пытаются переиспользовать один компонент поля для всех крайних случаев. Один TextField начинает обрабатывать маски, валюту, даты, асинхронный поиск, предупреждения, ошибки сервера и особые правила для одного экрана. Такой компонент перестаёт быть переиспользуемым, потому что пытается делать всё сразу. Простой input плюс несколько узких обёрток читать гораздо легче.

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

Команды часто игнорируют серверную валидацию до позднего QA. Это дорогая привычка. В браузере форма выглядит валидной, а API отклоняет дублирующийся tax ID, заблокированный email-домен или устаревшую цену. Подтягивайте эти правила раньше, сопоставляйте ошибки сервера с полями и оставляйте место для ошибок, которые относятся ко всей форме целиком.

Большинство React form libraries могут поддержать аккуратную настройку. Хаос обычно начинается тогда, когда одно правило может жить в трёх местах, и никто не решает, какое из них главное.

Быстрые проверки перед тем, как принять решение

Сначала выберите одну неудобную форму и соберите её по-настоящему, а уже потом решайте, какую библиотеку брать. Простая форма регистрации говорит очень мало. А вот экран онбординга клиента с несколькими контактами, условными полями, значениями по умолчанию из API и логикой сброса быстро покажет правду.

Хорошие React form libraries на таком экране ощущаются скучно. Вы можете проследить данные, найти ошибку, изменить правило и идти дальше. Плохие заставляют гоняться за состоянием по custom hooks, обёрткам и файлам валидации, которые уже не совпадают друг с другом.

Перед решением используйте короткий список проверок:

• Нарочно сломайте одно правило валидации и попросите нового разработчика проследить его от поля до схемы. Если это занимает больше минуты-двух, форма плохо переживёт время.
• Добавьте, удалите и переставьте строки в списке контактов. Посмотрите, остаются ли значения, touched state и ошибки у правильной строки.
• Загрузите значения по умолчанию из API, измените несколько полей, затем сбросьте форму. Она должна вернуться в чистое, предсказуемое состояние без устаревших ошибок и наполовину обновлённых массивов.
• Напишите тест для условного правила, например отображения налоговых полей только для бизнес-аккаунтов. Если для этого нужен мок почти всего приложения, дизайн слишком запутан.
• Удвойте форму на бумаге. Добавьте ещё три секции и несколько условных веток. Если файл уже сейчас кажется тесным, рост превратит его в проблему сопровождения.

Одна проверка важнее, чем многие признают: может ли новый человек читать код без экскурсовода? Если обработка ошибок живёт в одном месте, состояние полей — в другом, а правила схемы — в третьем, каждая правка начинает занимать больше времени. Эта цена проявляется через месяцы, когда небольшое изменение съедает весь день.

К полям-массивам стоит относиться особенно подозрительно. В демо они выглядят нормально, а потом ломаются, когда пользователи меняют порядок строк или удаляют второй элемент из пяти. Если ошибки хотя бы один раз прыгают не в ту строку, двигайтесь дальше.

Лучший выбор часто — это тот, код которого ваша команда сможет прочитать в 6 вечера в пятницу и всё ещё доверять ему после очередного изменения продукта.

Что делать дальше в кодовой базе

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

Ищите одну и ту же боль каждый раз: правила, продублированные в трёх местах, строки массива, которые ломаются при изменении порядка или удалении, и submit handler, набитый разовыми проверками. Если одна форма работает с контактами клиентов, а другая — с ценами или онбордингом, этого обычно уже достаточно, чтобы понять масштаб проблемы.

Во время аудита выписывайте только несколько фактов для каждой формы:

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

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

Запишите два правила и сделайте их короткими. Одно правило должно говорить, где живут схемы. Например, держите schema validation in React рядом с моделью формы и не дублируйте те же правила внутри UI-компонентов. Второе правило должно говорить, как работают массивы. Например, каждая повторяющаяся группа должна использовать массивный API библиотеки, стабильные item IDs и один общий способ добавлять или удалять строки.

Такая маленькая дисциплина важнее, чем логотип библиотеки. Команды попадают в неприятности, когда выбирают Formik, React Hook Form или TanStack Form, а потом продолжают писать каждый экран в своём стиле.

Если вашей команде нужен второй взгляд перед окончательным решением, Oleg Sotnikov может проверить архитектуру ваших React-форм в рамках Fractional CTO или startup advisory. Такой разбор часто помогает сразу увидеть неудачное разделение схем, слабую работу с массивами или план миграции, который через шесть недель снова создаст тот же хаос.