Работал ли со сложными формами

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

Определение "сложной формы"

Под "сложной формой" я подразумеваю не просто пару полей input. Это форма, которая:

• Имеет динамическую структуру: поля добавляются/удаляются пользователем (например, список участников, адресов доставки).
• Содержит зависимые поля: значение одного поля влияет на доступность, значение или валидацию другого (выбор страны -> подгрузка регионов -> подгрузка городов).
• Требует сложной валидации: как синхронной (на стороне клиента, с кастомной логикой), так и асинхронной (проверка на сервере, например, уникальность email или логина).
• Обладает многошаговой логикой (wizard): разбита на несколько шагов с сохранением промежуточных данных.
• Работает с вложенными или нерегулярными данными, которые сложно представить в виде плоского объекта.
• Интегрируется с сторонними сервисами для подсказок (геокодирование, поиск товаров).

Ключевые проблемы и подходы к решению

1. Управление состоянием

Ручной манипиляцией DOM или локальным состоянием компонентов (useState) здесь не обойтись. Я использую специализированные библиотеки:

• React Hook Form: Мой основной выбор для большинства проектов. Она обеспечивает неконтролируемые компоненты с привязкой к ref, что минимизирует ререндеры и повышает производительность даже для форм с сотнями полей.
• Formik: Использовал в legacy-проектах. Предоставляет более императивный API и полный контроль, но может страдать от проблем с производительностью на очень больших формах.
• Для комплексных связок "форма + общее состояние приложения" интегрирую их с Zustand или Redux Toolkit.

Пример базовой структуры сложной формы с React Hook Form и динамическими полями:

import { useForm, useFieldArray } from 'react-hook-form';

const DynamicForm = () => {
  const { control, register, handleSubmit } = useForm({
    defaultValues: { users: [{ firstName: '', lastName: '' }] }
  });
  const { fields, append, remove } = useFieldArray({
    control,
    name: "users"
  });

  const onSubmit = (data) => console.log(data);

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      {fields.map((field, index) => (
        <div key={field.id}>
          <input
            {...register(`users.${index}.firstName`)}
            placeholder="First Name"
          />
          <input
            {...register(`users.${index}.lastName`)}
            placeholder="Last Name"
          />
          <button type="button" onClick={() => remove(index)}>
            Удалить
          </button>
        </div>
      ))}
      <button type="button" onClick={() => append({ firstName: '', lastName: '' })}>
        Добавить пользователя
      </button>
      <button type="submit">Отправить</button>
    </form>
  );
};

2. Валидация

Я реализую многоуровневую валидацию:

• На стороне клиента: с использованием встроенных схем React Hook Form или библиотек типа Yup или Zod для декларативного описания правил. Zod особенно хорош благодаря TypeScript-нативной поддержке.
• На стороне сервера: обязательно дублирую критичную логику (например, проверку уникальности). Результаты асинхронной валидации интегрирую в общий поток отображения ошибок.

import { z } from 'zod';
import { zodResolver } from '@hookform/resolvers/zod';

// Схема валидации с зависимыми полями
const formSchema = z.object({
  age: z.number().min(18, "Только для взрослых"),
  hasDriverLicense: z.boolean(),
  licenseNumber: z.string().optional()
}).refine((data) => {
  // Кастомная логика: номер прав обязателен, если есть права
  return !data.hasDriverLicense || (data.hasDriverLicense && data.licenseNumber);
}, {
  message: "Введите номер водительского удостоверения",
  path: ["licenseNumber"] // Указываем, к какому полю привязать ошибку
});

3. Производительность и UX

• Оптимизация ререндеров: Использую React.memo для частей формы, изолирую состояния с помощью useFormContext или разбиваю форму на независимые подформы.
• Ленивая загрузка и код-сплиттинг: Для многошаговых форм загружаю логику и компоненты следующего шага только по необходимости.
• Дебаунс и троттлинг: Для полей с авто-сохранением или подсказками (автодополнение) обязательно применяю дебаунс, чтобы не завалить сервер или API запросами.

4. Архитектура и переиспользование

Я выношу логику полей в отдельные контролируемые компоненты (FormInput, FormSelect, FormAddress), которые инкапсулируют:

• Валидацию и отображение ошибок.
• Стилизацию и состояние (focus, blur).
• Интеграцию со сторонними UI-библиотеками (Material-UI, Ant Design).
• Логику загрузки зависимых данных (через кастомные хуки).

5. Тестирование

Сложные формы требуют тщательного тестирования:

• Юнит-тесты для кастомных валидаторов и хуков.
• Интеграционные тесты (с помощью React Testing Library) для проверки взаимодействия пользователя с формой: добавление полей, срабатывание валидации, отправка данных.
• E2E-тесты (например, на Cypress) для проверки полного цикла работы формы в браузере, включая интеграцию с бэкендом.

Вывод

Работа со сложными формами — это постоянный поиск баланса между гибкостью, производительностью и удобством поддержки. Мой опыт позволяет мне не просто реализовывать такие формы, но и проектировать их архитектуру, предвосхищая потенциальные проблемы с масштабированием, доступностью (a11y) и интеграцией в общую экосистему приложения. Я рассматриваю форму не как изолированный элемент, а как критичную часть бизнес-логики, требующую продуманного подхода на всех этапах разработки.