Розробка інтерактивної форми з розгалуженням (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% на доопрацюваннях, а вартість фіксується в договорі.