Разработка интерактивной формы с ветвлением (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 статическая
| Характеристика | Статическая форма | Форма с ветвлением |
|---|---|---|
| Количество полей для пользователя | Всегда максимальное | Только релевантные (сокращение на 40–60%) |
| Гибкость изменений | Требует деплоя | Меняется через JSON-конфигурацию |
| Конверсия | Базовая | Выше на 20–40% |
| Сложность реализации | Низкая | Средняя (требует движка) |
Форма с ветвлением превосходит статическую по конверсии в 1.5-2 раза: по нашим данным, конверсия выше на 20–40%, а количество полей сокращается на 40–60%.
Дополнительная таблица: операторы условий
| Оператор | Описание | Пример |
|---|---|---|
equals |
Равенство значения | "contact_type" == "ИП" |
not_equals |
Неравенство | "status" != "active" |
contains |
Вхождение подстроки | "email" contains "@" |
greater_than |
Числовое больше | "age" > 18 |
is_empty |
Поле пустое | "phone" is empty |
Как избежать проблем с производительностью?
При большом количестве полей (50+) и сложных правилах проверка условий может вызывать задержки. Решение — мемоизация вычисляемых полей и debounce на watch. В нашем движке каждый вызов shouldShowField кэшируется до изменения зависимого поля. Это снижает нагрузку на рендер до единиц миллисекунд даже на формах с сотней полей. Дополнительно используем debounce на 300 мс для watch, чтобы избежать лишних пересчетов.
Типичные ошибки при реализации
Первая ошибка — неучтённые edge-кейсы. Например, при смене выбора поля, уже скрывшего другие, нужно корректно очищать их значения. Вторая — отсутствие серверной валидации: клиентская логика может быть обойдена, поэтому все правила дублируются на бэкенде. Третья — сложные цепочки зависимостей: если поле A зависит от B, а B от A — возникает циклическая зависимость. Её нужно обнаруживать на этапе загрузки конфигурации. Четвертая — отсутствие логирования срабатывания правил, что усложняет отладку.
Процесс работы
- Аналитика — обсуждаем сценарии, рисуем майнд-карту ветвления.
- Проектирование — описываем JSON-схему правил, определяем типы полей.
- Реализация — пишем движок, компоненты и конфигуратор.
- Тестирование — проверяем все цепочки условий, в том числе edge-кейсы.
- Деплой — размещаем на продакшене, передаём доступ к конфигуратору.
- Поддержка — на протяжении 30 дней после сдачи отвечаем на вопросы и исправляем недочеты.
Что входит в разработку
- Проектирование JSON-схемы правил и типов полей
- Разработка движка условной логики (React-компоненты + серверный парсер)
- Интеграция с вашей CRM или любым API (Битрикс24, AmoCRM, HubSpot)
- Админ-панель для управления правилами без деплоя
- Документация конфигурации
- Обучение менеджеров работе с конфигуратором
- Техническая поддержка 30 дней
Сроки и стоимость
Форма с движком условной логики и JSON-конфигурацией разрабатывается за 4–6 рабочих дней. Стоимость рассчитывается индивидуально и зависит от сложности интеграций и количества сценариев. Срок может увеличиться при сложной интеграции или нестандартных анимациях — мы оцениваем каждый проект отдельно. Разработка кастомных форм React с серверной конфигурацией — наша специализация, более 50 внедрений.
Закажите форму с условной логикой для вашего проекта — мы проанализируем задачу за один рабочий день. Получите консультацию — мы проанализируем вашу задачу и предложим оптимальное решение. Опыт наших инженеров — более 10 лет в веб-разработке, более 50 внедрений форм с ветвлением. Гарантируем стабильную работу и быструю поддержку после сдачи. Экономия бюджета при использовании серверной конфигурации составляет до 50% на доработках, а стоимость фиксируется в договоре.