Как я похоронил три недели жизни в блоке T123, или почему сложные калькуляторы ломают Тильду

Я занимаюсь веб-разработкой уже девятый год. За это время я научился спокойно относиться к капризам заказчиков, падениям серверов и даже к правкам в ночь перед релизом. Но есть одна вещь, от которой у меня до сих пор дергается левый глаз. Это фраза: «Нам тут нужно на сайт накидать простенький калькулятор, там буквально пара шагов и ветвление логики».

Два года назад ко мне пришел клиент. Ребята строили каркасные бани и модульные дома. Бюджет на калькулятор был скромный — 40 000 рублей. По ТЗ все выглядело безобидно: пользователь выбирает площадь, тип фундамента, материал отделки и получает примерную стоимость. Сначала всё шло отлично. Я за пару часов набросал дизайн в Zero Block, открыл блок T123 для кастомного HTML/JS и приготовился быстро забрать деньги.

Я закончил этот проект через 19 дней. На 17-й день я сидел перед монитором в три часа ночи, тупо смотрел на 1400 строк спагетти-кода в VS Code и пытался понять, почему при выборе свайного фундамента и финской сауны итоговая цена уходит в минус. Это был ад.

Ловушка «простого» JS-кода в Тильде

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

Первая мина — это состояние (state). В обычном линейном квизе все просто: ответил на вопрос, перешел дальше. В калькуляторе с ветвлением пользователь постоянно ходит туда-сюда. Он дошел до третьего шага, передумал, вернулся на первый, поменял размер бани с 6х4 на 4х4, а потом снова нажал «Далее». Если вы пишете код на коленке, ваши переменные внутри JS не очистятся автоматически. В итоге в корзину или на отправку улетит дикая смесь из параметров разных шагов. Цена сломается, клиент получит неверную смету, а менеджер в CRM сойдет с ума.

Вторая мина — валидация полей. Стандартные формы Тильды умеют проверять, заполнено ли поле. Но они понятия не имеют, как валидировать динамические поля, которые появляются только при определенных условиях. Например, если пользователь выбрал «доставку за МКАД», должно появиться поле «расстояние в км», и оно обязано принимать только цифры больше нуля. Если писать это руками в T123, вы быстро обнаружите, что штатная отправка формы Тильды либо игнорирует ваши проверки, либо отправляет пустые данные.

И третья, самая болезненная мина — это вебхуки и передача данных в CRM. Вы можете написать красивый скрипт, который прямо на экране считает правильную сумму. Но когда пользователь нажимает кнопку «Отправить», Тильда забирает данные из своих стандартных инпутов. Если ваши расчеты происходили внутри виртуального JS, AmoCRM или Битрикс24 получат просто имя и телефон, а вся конфигурация заказа останется в воздухе. Или, что еще хуже, уйдет каша из скрытых полей, которую менеджер физически не сможет расшифровать.

Как проектировать такие штуки, чтобы не сойти с ума

Если вы все же решили собирать такой инструмент самостоятельно, забудьте про подход «сейчас быстренько допишу пару условий в jQuery». Это путь в никуда. Вот три правила, которые спасли мои последующие проекты.

Во-первых, жестко разделяйте интерфейс и логику. Не привязывайте расчет цены к классам элементов на странице. Создайте один глобальный объект конфигурации в JS — так называемый «источник правды». Все клики пользователя должны менять только этот объект. А уже специальная функция-рендерер должна считывать этот объект и обновлять цифры на экране. Изменился фундамент? Обновили одну строчку в объекте, вызвали перерасчет. Только так.

Во-вторых, храните матрицу цен отдельно. Никогда не пишите формулы вида if (material === 'wood') price += 5000 прямо внутри обработчиков событий. Завтра дерево подорожает на 15%, и вам придется переписывать весь код, рискуя сломать логику переходов. Сделайте в начале скрипта чистый JSON-конфиг со всеми тарифами.

В-третьих, перехватывайте отправку формы. Вам придется полностью отключить стандартный сабмит Тильды через event.preventDefault(), самостоятельно собрать финальный payload из вашего JS-объекта, записать его в скрытое текстовое поле формы и только после этого программно инициировать отправку. Тогда в вашу CRM прилетит аккуратный, понятный список выбранных опций и честная итоговая цена.

Когда стоит вовремя остановиться

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

Мы в GuardLabs съели на этом не одну собаку. Мы берем на себя всю грязную работу по созданию кастомных интерфейсов с нестандартной логикой расчета, валидацией «на лету» и бесшовной передачей чистых данных в вашу CRM. Если вам нужен надежный, не ломающийся от каждого чиха Многошаговый калькулятор с условной логикой на Тильде, который будет приносить заказы, а не головную боль — просто доверьте эту задачу нам.