Как добавить заезд и выезд в форму на Тильде
Для простой заявки на аренду не нужен сложный календарь: два штатных поля «Заезд» и «Выезд» понятнее клиенту и надёжно уходят в заявку. Единый календарь нужен, когда важно выбрать период одним движением, проверить минимальное число ночей и исключить отдельные даты. Даже тогда браузерная модификация только собирает пожелание — она не резервирует номер и не знает реальную занятость.
Короткий ответ
Если менеджер всё равно подтверждает даты вручную, поставьте два стандартных
поля: Заезд и Выезд. Модификация диапазона оправдана, когда нужен единый
календарь, минимальный срок и исключения. Синхронизация занятости — отдельная
интеграция с сервером бронирования, а не настройка календаря.
Вариант без кода: два поля даты
Добавьте в форму два поля одного типа и дайте им разные имена переменных:
| Подпись посетителю | Имя в заявке | Обязательное |
|---|---|---|
| Дата заезда | CheckIn | да |
| Дата выезда | CheckOut | да |
Не называйте оба поля Date: в письме или таблице станет непонятно, какое
значение относится к началу, а какое к концу.
Рядом добавьте короткую подпись: «Даты подтвердит менеджер». Это честнее зелёных и красных дней, которые никто не синхронизирует с реальной бронью.
Когда нужен единый календарь
Один интерфейс выбора периода полезен, если:
- посетитель должен видеть длину поездки;
- есть минимальный срок, например две ночи;
- заезд запрещён в отдельные дни недели;
- небольшой список дат надо закрыть вручную;
- на телефоне два независимых календаря создают путаницу.
Но в заявку всё равно лучше отправлять два значения. CRM может сортировать и фильтровать даты, а менеджер не разбирает строку «12–17 августа» вручную.
Что уже делает форма Тильды
Родное поле умеет одну дату и проверяет её формат. В рантайме для этого есть
t_datepicker__readDateFromInput и t_datepicker__isDateValid.
Тильда также даёт форменному коду безопасную запись значения через
t_formsApi__safeSetValue. Это важная техническая деталь: простое
input.value = ... может изменить то, что видно глазами, но не уведомить
остальную логику формы. Повторно отправлять событие change тоже не надо —
безопасный метод уже делает это сам.
Дизайнеру запоминать названия функций не требуется. Они нужны как критерий для готового мода: если автор календаря пишет напрямую в поле и отдельно имитирует события, интеграция с условиями формы может пересчитаться дважды.
Честная граница занятости
Есть три уровня:
- Две даты в заявке. Решается штатной формой.
- Удобный диапазон и ручные исключения. Решается браузерной модификацией.
- Актуальные остатки, удержание слота и оплата. Решается системой бронирования.
Третий уровень нельзя получить файлом в T123. Нужен единый серверный источник, который проверяет занятость в момент подтверждения. Иначе два открытых браузера одновременно увидят одну свободную дату.
MOD-173 ограничен вторым уровнем: один календарь, минимальный срок, ручной список исключений, две даты и длительность в заявке. Карточка не обещает API отеля или защиту от двойного бронирования.
Проверка перед клиентским показом
Пройдите не только красивый основной сценарий:
- конец одного месяца и начало другого;
- 29 февраля високосного года;
- попытка выбрать выезд раньше заезда;
- период короче минимального;
- недоступная дата внутри выбранного диапазона;
- управление Tab, стрелками, Enter и Escape;
- повторное открытие с уже выбранными датами;
- отправка и чтение значений в конечной CRM.
На телефоне убедитесь, что календарь не уходит под клавиатуру и кнопку отправки. Если посетитель не может закрыть его без перезагрузки страницы, форма не готова.
Что оставить клиенту
Запишите, где меняется минимальный срок и список исключений, кто отвечает за их актуальность и какой текст предупреждает о ручном подтверждении. Если позже появится система бронирования, ручной список надо удалить, а не вести рядом два источника правды.