tea.Batch и tea.Sequence: комбинации команд

tea.Batch(cmds ...Cmd) — вариадическая функция: принимает сколько угодно команд и возвращает одну. Фреймворк разворачивает её и запускает все команды одновременно, каждую в своей горутине. Сообщения приходят в Update по мере завершения: какая работа закончилась раньше, то сообщение и прилетело первым. Никакой синхронизации между командами нет — Batch это чистый fan-out: раздал задачи, собрал результаты. Идеальный клиент — независимые операции: загрузка настроек, тик спиннера, проверка версии на сервере. Ни одна не ждёт другую, значит, параллельность только ускорит старт. Механика честная: изнутри Batch возвращает команду со списком остальных, которую фреймворк разворачивает рекурсивно, — для вас это невидимо и не меняет правил игры. Ключевое следствие, которое стоит выучить наизусть: Batch не даёт никаких гарантий порядка сообщений. Ни «первая в списке придёт первой», ни «порядок стабильный между запусками». Первым придёт тот, кто закончил, — и точка. Всё, что построено на предположениях об этом порядке, построено на песке; почему — увидим на примере ниже.

tea.Sequence(cmds ...Cmd) запускает команды последовательно: следующая стартует только после того, как сообщение предыдущей дошло до Update. Это конвейер с очередью шагов, и он нужен всюду, где порядок — часть смысла. Классический пример — протокол: сначала connectCmd, потом authCmd, потом loadTasksCmd. Запускать их пачкой бессмысленно: авторизация без установленного соединения просто упадёт, и вы получите три ошибки вместо одной. Sequence превращает этот список в детерминированную цепочку: каждый шаг гарантированно видит результат предыдущего — потому что он уже обработан в Update и разложен по модели. Плата за порядок — скорость: суммарное время равно сумме шагов, параллельности нет. Поэтому правильный вопрос при выборе — не «что быстрее», а «зависит ли шаг от предыдущего». Зависит — Sequence. Не зависит — Batch. Sequence выручает и в сценариях онбординга: показать приветствие, дождаться подтверждения, загрузить первый экран — тоже цепочка шагов. Комбинации обоих закрывают остальные случаи.

Самая частая ошибка с Batch выглядит невинно. В Init возвращают Batch(loadConfigCmd(), loadTasksCmd()), а в Update ловят сообщение настроек раньше сообщения задач и строят на этом логику: «настройки пришли первыми, применю их до отрисовки». На машине разработчика с локальной базой это работает месяцами. Потом программа уезжает к пользователю с медленной сетью, настройка начинает приходить позже задач — и экран стартует с пустым профилем. Я ловил именно такой баг в панели мониторинга: две команды в Batch, на моей машине порядок был стабильным год, а у коллеги в другом дата-центре — противоположным. Диагностика мучительная, потому что баг «плавает». Лечение — принципиальное: Batch годится только для независимых команд, а если B не может работать без результата A, между ними Sequence или второй заход через Update. Никогда не угадывайте порядок — проектируйте код, которому порядок безразличен.

Batch и Sequence возвращают обычный tea.Cmd — значит, их можно скармливать друг другу и смешивать со своими командами на любом уровне. Механика честная: BatchMsg изнутри разворачивается фреймворком рекурсивно, и глубже одного-двух уровней уходить обычно не приходится. Живой шаблон старта: Sequence снаружи, потому что этапы зависят друг от друга, а внутри этапа — Batch из независимых задач. Так вы получаете и порядок фаз, и параллельность внутри фазы. Обратная комбинация — Batch из последовательностей — встречается реже, но уместна, когда несколько независимых протоколов идут параллельно, и каждый — по шагам. Полезная привычка: читать такие вложенности как дерево, где ветка Sequence исполняется вертикально, а ветка Batch — веером. Если дерево в голове не собирается, код для читающего соберётся ещё меньше — дробите на именованные функции-команды.

Второй шаблон, где Batch незаменим, — одинаковая работа по списку. Десять адресов, которые нужно пропинговать; двадцать файлов, которые нужно прочитать; пакетный индекс, который надо обновить по одному элементу. Решение механическое: в цикле сгенерируйте срез команд и отдайте его в tea.Batch пачкой. Фабрика-замыкание из пятого урока здесь главное действующее лицо: каждый элемент списка захватывается своим замыканием, и команды не путаются между собой, а ошибка элемента возвращается его же командой — сразу понятно, кто виноват. Сотни одновременных команд фреймворку не страшны — горутины дешёвые. Страшна цель: если адресатов тысячи, подумайте о пуле ограничений — слишком много одновременных соединений упрутся в лимиты сервера или самого терминала по отрисовке сообщений. Простой вариант — нарезать список на куски и планировать следующий Batch из Update, когда предыдущий отчитался. А материал для настоящих сетевых fan-out'ов ждёт в уроке про HTTP-данные.

Параллельность пугает, если привыкли к потокам с блокировками. В Bubble Tea гонок между вашими командами почти не бывает — и вот почему. Команды не делят состояние: каждая работает со своими аргументами и возвращает сообщение, а всё состояние меняет один-единственный Update, который обрабатывает сообщения строго по одному. Пока вы держитесь этого правила elm архитектуры, параллельный Batch безопасен по построению: каким бы ни был порядок, каждая обработка видит целостную модель. Проблемы начинаются не от параллельности, а от ожиданий: код, который предполагает порядок прибытия или однократность события, — уже не конкуренция за память, а логическая гонка, и таблица Batch против Sequence выше — про неё. Противоядие то же: пишите обработчики так, будто каждый факт может прийти в любой момент и даже дважды — идемпотентно и без предположений о соседях. Тогда скорость пачки достаётся бесплатно, а редкие порядки превращаются из багов в просто события.

Комбинаторы закрыли дыру «одна команда на событие» — и попутно показали, что модель умеет разрастаться. Когда загрузок и панелей становится много, Update начинает нуждаться в порядке не меньше, чем Init: восьмой урок про композицию подмоделей учит делить экран и сообщения между частями программы. Тики часов и таймауты — те же команды, собранные через Batch, — разбирает урок про tea.Tick и таймеры. А если хотите освежить одиночные команды, вернитесь к пятому уроку или откройте страницу курса Bubble Tea — там вся программа из 25 уроков. Практика на сегодня: возьмите старт из примера с Sequence, добавьте четвёртый этап loadLogsCmd и замерьте локально, как меняется время до первого кадра, если переставить фазы местами.