Черновик в Telegram Mini App нужен, чтобы человек мог продолжить заполнение после закрытия окна, короткого сбоя или возврата из другого чата. Но обещание «всё сохраняется» требует точного смысла. Данные на одном устройстве, запись на сервере и подтверждённая заявка имеют разные гарантии и разные условия доступности.
Поэтому сначала определяют, что именно сохраняется, когда и где. Локальное хранение может помочь пережить перезагрузку интерфейса, но не заменяет серверную связь с пользователем. Ниже разобрана схема для многошаговой формы без предположения, что любое доступное хранилище Telegram подходит всем видам данных.
Черновик и отправленная заявка
Черновик содержит ещё не подтверждённые сведения. Пользователь может менять их и отказаться от отправки. Подтверждённая заявка уже участвует в рабочем процессе команды. Не создавайте настоящий заказ при каждом локальном сохранении только потому, что так проще использовать одну таблицу.
У черновика нужен собственный идентификатор, версия формы, время изменения и состояние. Эти поля помогают отличить новую анкету от старой. Один ключ «последняя форма» плохо работает, если человек начинает несколько независимых задач либо открывает приложение на двух устройствах.
В интерфейсе объясните момент сохранения. Если данные записываются после выхода из поля, не обещайте сохранность последней неподтверждённой буквы при внезапном закрытии. Если сохранение выполняется на сервере, отображайте фактический результат, а не только начало сетевого запроса.
Где хранить данные
У Mini Apps есть документированные средства хранения, а веб-приложение может иметь собственную серверную базу. Выбор зависит от назначения и поддерживаемой версии клиента. Перед использованием DeviceStorage, CloudStorage или SecureStorage проверьте текущие возможности и ограничения, а не переносите их свойства друг на друга.
Локальный черновик удобен для продолжения на том же устройстве, если механизм доступен и данные сохраняются по его правилам. Серверный нужен, когда требуется устойчивое продолжение между устройствами или доступ операторского процесса. Но серверная запись требует правильной идентификации и проверки прав на конкретный черновик.
SecureStorage не является универсальной большой базой анкет. Его назначение и ограничения описаны отдельно. Не храните токен бота в клиенте ни в каком варианте, считая само название хранилища достаточной защитой. Пользовательская сессия и постоянный серверный секрет — разные категории данных.
Момент сохранения и сигнал пользователю
Сохраняйте после значимых изменений с разумным управлением частотой. Сетевой запрос на каждую букву может быть избыточным, а запись только при финальном подтверждении не обеспечивает обещанное продолжение. Конкретный подход выбирают по размеру формы, скорости сети и требованиям к сохранности.
Покажите различие между «изменения есть», «сохраняется» и «сохранено», если оно важно для сценария. Не держите человека в постоянной тревоге, но дайте понятный результат перед выходом. При ошибке предложите повтор либо другой доступный путь без уничтожения текста.
Отдельно проверяйте последнюю версию ответа. Более старый сетевой запрос может завершиться позже нового и затереть актуальные данные, если сервер принимает всё подряд. Нужны правило версии, порядок применения или иной поддерживаемый механизм. Красивый индикатор сохранения не решает конфликт сам.
Условный пример: длинное описание проблемы
Предположим, пользователь заполняет заявку поддержки и пишет несколько абзацев. Он сворачивает Mini App, чтобы посмотреть версию программы, затем возвращается. Приложение предлагает продолжить тот же черновик с сохранённой темой и описанием. Новая заявка не создаётся от одного повторного открытия.
На другом устройстве тот же человек открывает форму. Если проект поддерживает серверные черновики, он видит актуальную запись после проверки доступа. Если поддерживается только локальное продолжение, приложение не должно обещать перенос между устройствами. Ограничение объясняют в подходящем месте, а не после потери введённого текста.
Это условный пример. Telegram предоставляет средства платформы, но синхронизация, версия анкеты и серверная модель принадлежат вашему приложению. Наличие CloudStorage не означает автоматически готовый порядок конфликтов или подтверждения заявки в CRM.
Два устройства и конфликт изменений
Если пользователь редактирует один черновик параллельно, определите правило. Простая победа последнего полученного запроса может потерять сведения с другого устройства. Иногда допустимо показать конфликт и предложить выбрать актуальную версию; иногда процесс предусматривает отдельные экземпляры формы.
Не объединяйте свободный текст вслепую. Два описания могут противоречить друг другу или содержать исправление старого значения. Для структурированных полей полезно показать, что изменилось. Пользователь должен понимать итог перед отправкой, особенно если черновик долго существовал и редактировался в разных местах.
Сводка подтверждения строится из сохранённой актуальной версии, а не из случайного локального состояния старой вкладки. После отправки экземпляр получает окончательное состояние. Старый клиент не должен снова превратить его в черновик или создать дубль при следующем автоматическом сохранении.
Срок хранения и очистка
Определите срок актуальности по задаче. Черновик записи на конкретное время может устареть быстрее общего обращения. При возвращении проверьте внешние условия: выбранный слот или услуга уже могли измениться. Сохранённый текст не означает сохранённую доступность ресурса.
Очистка должна охватывать используемые копии по установленному процессу. Если сервер удалил черновик, но локальная вкладка позже загружает старую версию, данные могут появиться снова. Учитывайте состояние удаления и порядок синхронизации, а не только периодическую очистку одной таблицы.
Не храните больше сведений, чем нужно для продолжения. Для формы обычно достаточно пользовательских ответов и технического контекста. Полная история действий и сторонние документы требуют отдельного назначения и правил доступа. Черновик не должен становиться скрытой бессрочной копией всей переписки.
Ошибки и неподдерживаемые возможности
Проверьте отсутствие выбранного клиентского API и отказ записи. Если функция хранения недоступна, приложение может перейти к серверному варианту или честно обозначить ограничение, если это предусмотрено. Не вызывайте отсутствующий метод без проверки, превращая удобство в причину чёрного экрана.
При потере соединения сохраняйте понятное локальное состояние в допустимом объёме и не заявляйте серверный успех. После восстановления сверяйте версии. Если финальная отправка уже выполнилась, повтор не должен создавать ещё одну заявку из оставшегося черновика.
Отдельно испытайте выход из учётной записи и отзыв связи. Черновик не должен быть доступен другому пользователю только потому, что он открыл приложение на том же устройстве. Проверка принадлежности выполняется на сервере, а локальная очистка учитывает выбранную модель сессии.
Приёмка
Пройдите сохранение, перезагрузку, закрытие, возврат и параллельное редактирование. Затем испытайте старую версию формы, ошибку сети и удаление черновика. Используйте вымышленные сведения и известный ожидаемый результат для каждого шага.
Черновик готов к работе, когда человек понимает, что сохранено и как продолжить, а приложение не теряет актуальную версию и не создаёт повторные заявки. Проверяемая граница хранения полезнее широкой фразы об автоматическом сохранении всего без известных ограничений.
Финальная отправка и оставшаяся локальная копия
После успешной заявки черновик должен получить завершённое состояние. Если приложение просто закрывает окно, старые данные могут остаться в локальном хранилище и при следующем входе выглядеть как новая незавершённая форма. Пользователь отправит их повторно, не понимая, что первая заявка уже существует.
Проверьте очистку либо отметку завершения на всех используемых уровнях. При потере ответа сначала выясняйте результат операции по собственному идентификатору, а не создавайте новую заявку из той же формы. На тесте отправьте анкету, закройте приложение до показа подтверждения и откройте снова. Интерфейс должен показать существующий результат или понятную проверку состояния, сохраняя одну бизнес-операцию.
Источники
Средства хранения описаны в Telegram Mini Apps: CloudStorage, DeviceStorage и SecureStorage. Выбор механизма, серверные версии и правила черновика определяются вашим приложением.