Интерактивная форма с ветвлением: разработка conditional logic

Разработка интерактивной формы с ветвлением (Conditional Logic) на сайте

Мы часто сталкиваемся с ситуацией: пользователь заполняет форму из 30 полей, большинство из которых ему не нужно. Он юрлицо, а видит поле для паспортных данных. Бросает заполнение на середине. Такая ситуация — частая причина низкой конверсии. Мы решаем это с помощью условной логики: поля показываются или скрываются в зависимости от ответов. В итоге каждый видит только релевантные вопросы, а конверсия растёт на 20–40%. По данным Baymard Institute, длинные формы снижают конверсию на 80% — условная логика компенсирует этот эффект. Разрабатываем интерактивные формы с ветвлением под ключ за 4–6 дней.

Как работает условная логика в форме?

Основная идея: форма управляется правилами, описанными в JSON-конфигурации на сервере. Логику можно изменить без деплоя фронтенда — достаточно обновить файл конфигурации.

Движок условной логики

interface FieldRule {
  field: string; // поле, к которому применяется правило
  action: 'show' | 'hide' | 'require' | 'set_value';
  conditions: Condition[];
  logic: 'and' | 'or';
}

interface Condition {
  field: string;
  operator: 'equals' | 'not_equals' | 'contains' | 'greater_than' | 'is_empty';
  value: unknown;
}

function evaluateCondition(condition: Condition, formValues: Record<string, unknown>): boolean {
  const fieldValue = formValues[condition.field];
  switch (condition.operator) {
    case 'equals':
      return fieldValue === condition.value;
    case 'not_equals':
      return fieldValue !== condition.value;
    case 'contains':
      return String(fieldValue).includes(String(condition.value));
    case 'is_empty':
      return !fieldValue || fieldValue === '';
    case 'greater_than':
      return Number(fieldValue) > Number(condition.value);
    default:
      return false;
  }
}

function shouldShowField(rule: FieldRule, formValues: Record<string, unknown>): boolean {
  const results = rule.conditions.map(c => evaluateCondition(c, formValues));
  return rule.logic === 'and' ? results.every(Boolean) : results.some(Boolean);
}

Компонент формы с условной логикой

function ConditionalForm({ schema, onSubmit }: Props) {
  const { watch, register, handleSubmit } = useForm();
  const formValues = watch();
  const visibleFields = schema.fields.filter(field => {
    const rule = schema.rules.find(r => r.field === field.id);
    if (!rule) return true; // без правил — всегда показываем
    return rule.action === 'show' ? shouldShowField(rule, formValues) : !shouldShowField(rule, formValues);
  });
  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <AnimatePresence>
        {visibleFields.map(field => (
          <motion.div
            key={field.id}
            initial={{ opacity: 0, height: 0 }}
            animate={{ opacity: 1, height: 'auto' }}
            exit={{ opacity: 0, height: 0 }}
          >
            <FormField field={field} register={register} />
          </motion.div>
        ))}
      </AnimatePresence>
      <button type="submit">Отправить</button>
    </form>
  );
}

Почему стоит хранить правила на сервере?

Отметим: когда правила хранятся на сервере, маркетолог или менеджер может изменить логику формы через админку без участия разработчика. Это критически важно для A/B-тестов и быстрой реакции на поведение пользователей. Серверная конфигурация гарантирует единое поведение формы на всех устройствах и синхронизацию с валидацией на бэкенде.

Пример конфигурации

{
  "fields": [
    {
      "id": "contact_type",
      "type": "radio",
      "options": ["Физлицо", "ИП", "ООО"]
    },
    {
      "id": "company_name",
      "type": "text",
      "label": "Название компании"
    },
    {
      "id": "inn",
      "type": "text",
      "label": "ИНН"
    },
    {
      "id": "passport",
      "type": "text",
      "label": "Паспортные данные"
    }
  ],
  "rules": [
    {
      "field": "company_name",
      "action": "show",
      "logic": "or",
      "conditions": [
        {
          "field": "contact_type",
          "operator": "equals",
          "value": "ИП"
        },
        {
          "field": "contact_type",
          "operator": "equals",
          "value": "ООО"
        }
      ]
    },
    {
      "field": "passport",
      "action": "show",
      "logic": "and",
      "conditions": [
        {
          "field": "contact_type",
          "operator": "equals",
          "value": "Физлицо"
        }
      ]
    }
  ]
}

Конфигурация хранится на сервере — логика меняется без деплоя.

Сравнение: форма с условной логикой vs статическая

Форма с ветвлением превосходит статическую по конверсии в 1.5-2 раза: по нашим данным, конверсия выше на 20–40%, а количество полей сокращается на 40–60%.

Дополнительная таблица: операторы условий

Как избежать проблем с производительностью?

При большом количестве полей (50+) и сложных правилах проверка условий может вызывать задержки. Решение — мемоизация вычисляемых полей и debounce на watch. В нашем движке каждый вызов shouldShowField кэшируется до изменения зависимого поля. Это снижает нагрузку на рендер до единиц миллисекунд даже на формах с сотней полей. Дополнительно используем debounce на 300 мс для watch, чтобы избежать лишних пересчетов.

Типичные ошибки при реализации

Первая ошибка — неучтённые edge-кейсы. Например, при смене выбора поля, уже скрывшего другие, нужно корректно очищать их значения. Вторая — отсутствие серверной валидации: клиентская логика может быть обойдена, поэтому все правила дублируются на бэкенде. Третья — сложные цепочки зависимостей: если поле A зависит от B, а B от A — возникает циклическая зависимость. Её нужно обнаруживать на этапе загрузки конфигурации. Четвертая — отсутствие логирования срабатывания правил, что усложняет отладку.

Процесс работы

1. Аналитика — обсуждаем сценарии, рисуем майнд-карту ветвления.
2. Проектирование — описываем JSON-схему правил, определяем типы полей.
3. Реализация — пишем движок, компоненты и конфигуратор.
4. Тестирование — проверяем все цепочки условий, в том числе edge-кейсы.
5. Деплой — размещаем на продакшене, передаём доступ к конфигуратору.
6. Поддержка — на протяжении 30 дней после сдачи отвечаем на вопросы и исправляем недочеты.

Что входит в разработку

• Проектирование JSON-схемы правил и типов полей
• Разработка движка условной логики (React-компоненты + серверный парсер)
• Интеграция с вашей CRM или любым API (Битрикс24, AmoCRM, HubSpot)
• Админ-панель для управления правилами без деплоя
• Документация конфигурации
• Обучение менеджеров работе с конфигуратором
• Техническая поддержка 30 дней

Сроки и стоимость

Форма с движком условной логики и JSON-конфигурацией разрабатывается за 4–6 рабочих дней. Стоимость рассчитывается индивидуально и зависит от сложности интеграций и количества сценариев. Срок может увеличиться при сложной интеграции или нестандартных анимациях — мы оцениваем каждый проект отдельно. Разработка кастомных форм React с серверной конфигурацией — наша специализация, более 50 внедрений.

Закажите форму с условной логикой для вашего проекта — мы проанализируем задачу за один рабочий день. Получите консультацию — мы проанализируем вашу задачу и предложим оптимальное решение. Опыт наших инженеров — более 10 лет в веб-разработке, более 50 внедрений форм с ветвлением. Гарантируем стабильную работу и быструю поддержку после сдачи. Экономия бюджета при использовании серверной конфигурации составляет до 50% на доработках, а стоимость фиксируется в договоре.