Таймеры и реальное время: tea.Tick

Сигнатура короткая: tea.Tick(d, fn) принимает длительность и функцию func(time.Time) tea.Msg, а возвращает обычную команду. Верните её из Init или Update — фреймворк запустит, подождёт d и вызовет fn с текущим моментом времени; что fn вернёт, то и приедет в Update сообщением. Ключевое слово — одноразовость: одна команда стреляет один раз. Цепочка держится на самозапланировании, которое вы уже видели у спиннера: ветка tickMsg в Update обязана вернуть новую команду тика, иначе через секунду цепочка оборвётся и часы замрут. Сообщение принято объявлять типом-обёрткой над временем — type tickMsg time.Time: так оно не спутается с сырым time.Time, а внутри модели момент достаётся приведением time.Time(msg). Время в сообщении — не украшение: именно оно позволяет View показать момент события, а логам — понять, когда тик опоздал. Опоздания, кстати, реальны: под нагрузкой терминал собирает кадры, и секунда между тиками иногда превращается в полторы.

Модель хранит последний момент — поле now time.Time, — ветка tickMsg его обновляет и возвращает следующий тик, View форматирует. Конструктор ставит now в time.Now(): без этого до первого тика шапка покажет нулевое время рандомной эпохи, а целую секунду — заметно долго. Формат по-русски привычен: m.now.Format("15:04:05") выдаёт часы, минуты и секунды; раскладка шапки — занятие урока про раскладку Lip Gloss, здесь достаточно строки. Заметьте разделение труда: модель знает момент, View решает, как его показывать, а команда не знает ничего о том, зачем её позвали. Из-за этого часы можно переставить в футер или выкинуть совсем — правка затрагивает View и не трогает таймер. Проверять ход часов в песочнице бессмысленно — время эмулирует только живой терминал, поэтому запускайте локально: time.Second уменьшите до пары сотен миллисекунд, и бегущие цифры покажут и частоту, и опоздания кадров наглядно. Одна деталь, которую стоит видеть своими глазами: при потере фокуса окна терминал может приостановить отрисовку, и после возврата цифры прыгнут — модель ни при чём, догонять кадры не нужно.

Вторая работа таймера — дедлайны. Запрос ушёл на сервер — запланируйте рядом команду-таймаут: tea.Tick на пять секунд возвращает timeoutMsg, и если ответ не успел, ветка переводит модель в состояние ошибки с честным текстом «сервер молчит дольше пяти секунд». Для HTTP правильнее контекст из девятнадцатого урока — клиент отменяет запрос физически; таймер в модели нужен для произвольных операций: долгая индексация, воркер без таймаута, ответ от внешней программы. Но у таймера есть подвох, которого у контекста нет: он стреляет всегда, даже когда уже не нужен. Пользователь нажал r — загрузка перезапущена — а старый таймер первой попытки всё ещё в полёте и через пять секунд влепит ошибку в успешно загруженные данные. Лечение — метка принадлежности: у модели счётчик попыток gen, каждая команда-таймер уносит номер своей попытки, и ветка сравнивает msg.gen с текущим. Чужой таймер молча сгорает: return m, nil. Три строки страховки против загадочного флота ошибок через полминуты после успешной загрузки.

Секундный тик стоит денег: кадр перерисовывается, процессор просыпается, по SSH уходит пакет. Когда панель в фокусе и на ней смотрят часы — это цена правильная. Когда экран простаивает или свёрнут — секунда превращается в расточительность, и частоту стоит деградировать: раз в тридцать секунд вместо ежесекундно. Реализация честнее всего живёт в фабрике: интервал вычисляется из состояния модели, ветка тика просто возвращает tickCmd(m.interval()). Панель в фокусе — секунда; ушёл фокус — тридцать секунд; идёт загрузка — четверть секунды, чтобы спиннер жил. Заметьте направление зависимости: Update не решает частоту сам, он спрашивает у модели — состояние в одном месте, и тестировать интервал можно отдельной функцией без терминала. Деградация — не только про экономию: медленный тик на простаивающем дашборде означает, что возврат из скринсейвера не принесёт очередь из тридцати пропущенных кадров. Пропущенные тики догонять не нужно — опоздавший таймер просто рисует текущий момент, догонять нечего.

Альтернатива без хелпера выглядит так: return func() tea.Msg { return tickMsg(<-time.After(d)) } — горутина фреймворка блокируется на канале таймера и через d доставляет сообщение. Поведение то же, и в проектах такой вариант встречается. Различия мягкие, но есть. tea.Tick передаёт момент времени в функцию — время уже внутри сообщения; с time.After момент приходится собирать отдельно вызовом time.Now() в замыкании, и между выстрелом таймера и снимком момента успевает пройти ещё пара микросекунд. tea.Tick — каноническая идиома, по которой проект на Bubble Tea узнаётся с первого взгляда: grep по tea.Tick находит все таймеры репозитория. time.After прячет Timer, который живёт до срабатывания: для секунды незаметно, для часовых дедлайнов — уже счёт. Мое правило — tea.Tick везде, кроме одного случая: тесты подменяют реальное время фиктивными сообщениями, и там таймер не нужен вовсе, о чём подробно расскажет следующий урок. Ticker из стандартного пакета не трогаем: повторяющийся источник с обязательным Stop чужд архитектуре, где частота задаётся возвратом команды.

Цепочка тиков — последний кирпич каркаса: клавиши, команды, композиция, сеть и теперь время. Следующая остановка — тестирование TUI: там фиктивный tickMsg с заданным моментом проверит часы без единой секунды ожидания, а дедлайны проверят подменой таймера моком. Повторить материал спиннера можно в шестом уроке — там та же цепочка спрятана в готовый компонент. Для сетевых запросов дедлайном остаётся контекст из урока про HTTP — таймер модели дополняет его, но не заменяет. А урок про сборку и дистрибуцию покажет, где деградация частоты окупается по-настоящему: медленные SSH-сессии, где каждый кадр — пакет через океан. Обзор курса целиком — на странице Bubble Tea. Проверять тики честно можно только локально: поставьте интервал в сто миллисекунд, запустите панель в настоящем терминале и посмотрите, как опоздания под нагрузкой съедают ровность хода.