Данные из сети: HTTP-запросы в командах

Правило одно и жёсткое: сеть живёт только в команде. Фабрика — обычная функция, принимающая нужные аргументы и возвращающая готовое замыкание func() tea.Msg: fetchItemsCmd(url) захватывает строку и запускается позже, в горутине фреймворка. Внутри замыкания — обычный Go: http.Get, чтение тела, разбор. Три запрета из пятого урока действуют и здесь: команда не печатает в терминал, не паникует и не трогает модель — она не знает о её существовании. Ошибка любого этапа упаковывается в поле err сообщения-результата: команда вернулась — значит, событие произошло, а каким оно было, решает Update. Хорошая привычка — не отдавать наружу сырые байты: превратите тело в []Item внутри замыкания, тогда Update и View работают с доменными данными и не знают, откуда они приехали. Поменять источник с HTTP на файл или кэш — значит переписать одну фабрику, а не весь Update. Именование фабрик в живых проектах держится одного шаблона: fetchXCmd, loadXCmd, saveXCmd — по префиксу grep находит все сетевые точки программы за секунду, и это отдельный аргумент против инлайн-замыканий посреди Update: их потом не найти.

Данные из сети асинхронны, поэтому модель обязана знать, в какой фазе находится загрузка. Соблазн — три булевых поля loading, loaded, failed — работает плохо: компилятор не мешает комбинации loading и failed одновременно, и рано или поздно она появится. Честнее — один тип-перечисление: stateLoading, stateLoaded, stateError через iota, и модель хранит единственное поле state. Переходы очевидны: нажали r или старт — stateLoading, пришло сообщение с данными — stateLoaded, с ошибкой — stateError. View превращается в switch по состоянию: спиннер или строка «Загружаю...», список, ошибка с подсказкой. Отдельно про экран ошибки: «Ошибка: dial tcp: connection refused» без подсказки — тупик для пользователя, поэтому рядом всегда должна стоять дорога назад — «r — повторить». Ошибка из сети — не крах программы, а штатное состояние, которое она обязана уметь показывать и перезапускать. Полезный расширяемый случай — четвёртое состояние stateRefreshing: данные на экране есть, но поверх идёт обновление, и интерфейс показывает и то, и другое. Не заводите его заранее — на один список хватает трёх состояний, четвёртое появляется вместе с требованием продукта, не раньше.

Первый сюрприз новичка: http.Get не считает 404 и 500 ошибками. Значение err возвращается только когда запрос не состоялся физически — нет сети, не разрешилось имя, отвалится TLS. Ответ «404 Not Found» — полноценный *http.Response, и если статус не проверить, команда попытается распарсить страницу ошибки как JSON и упадёт с загадочным сообщением. Проверяйте resp.StatusCode руками и упаковывайте resp.Status в err. Второй сюрприз — тело надо закрывать: defer resp.Body.Close() в каждой ветке, где тело вообще открывалось, иначе пул соединений клиента исчерпается. Сам разбор: json.NewDecoder(resp.Body).Decode(&v) читает поток напрямую и не грузит весь ответ в память — для типичных API этого достаточно, а json.Unmarshal уместен, когда байты уже прочитаны другим кодом. Структуру под JSON описывают тегами, и это лучший кандидат на отдельный тип api-слоя, о котором Update не знает. Декодер понимает UTF-8 из коробки, а для недоверенных источников размер ответа стоит ограничить io.LimitReader: читать гигабайт мусора из чужого API не стоит.

Дефолтный http.Get использует глобальный клиент без таймаута: зависший сервер означает зависшую команду — навсегда. Лекарство двухуровневое. Сначала клиент с Timeout: http.Client{Timeout: 5 * time.Second} ограничивает всю жизнь запроса — от набора соединения до чтения тела. Затем контекст: http.NewRequestWithContext принимает context.Context, и контекст с WithTimeout даёт лимит конкретной операции, который жёстче клиентского. Зачем оба? Клиент — страховка от забывчивости, контекст — осознанное решение об операционном лимите, и оба числа озвучиваются в коде явно. В терминальном приложении контекст делает ещё одну вещь: отмену по уходу пользователя — если экран закрыт, а запрос ещё едет, cancel обрывает его и освобождает соединение. Для одного запроса это тонкость, для панели с десятью живыми запросами — гигиена. Про устройство контекстов, отмену и распространение по дереву вызовов подробнее рассказывает урок про context курса go-advanced. И практичная деталь: числа таймаутов не универсальны — пять секунд для обычного API нормально, для тяжёлого отчёта издевательство. Лимит передавайте фабрике команды параметром рядом с url, пусть решает вызывающий.

Оптимистичное обновление — приём, когда изменение применяется до ответа сервера: пользователь пометил задачу выполненной — модель перевернула галочку сразу, а подтверждение приедет позже. Ощущение скорости резкое: интерфейс отвечает со скоростью нажатия, а не сети. Цена — откат: пришла ошибка, и галочку придётся вернуть с честным сообщением. Где оптимизм уместен — на дешёвых обратимых операциях: пометки, лайки, сортировка. Где нет — на создании и удалении: запись, которой нет на сервере, откатывать мучительно для пользователя, поэтому такие действия честнее держать в состоянии loading до ответа. Мое правило — оптимистично только то, что откатывается одним присваиванием. Вторая половина темы — защита от повторов: пользователь жмёт r пять раз подряд, и наивная модель отправит пять параллельных запросов, ответы придут в случайном порядке и затрут друг друга. Флаг уже есть: если state равен stateLoading, ветка r просто игнорирует нажатие. И про порядок ответов: пять параллельных запросов приходят в случайном порядке, и последним может оказаться самый старый — ещё одна причина не плодить запросы, а перезапускать один текущий.

Данные нужны сразу — верните команду из Init, и загрузка стартует вместе с программой: Init() tea.Cmd { return fetchItemsCmd(m.url) }. До прихода ответа модель живёт в stateLoading, и экран не выглядит пустым. Спиннеру нужна собственная команда Tick из шестого урока, а на старте возвращается несколько команд сразу — их объединяет tea.Batch из седьмого: Batch(spinner.Tick, fetchItemsCmd(m.url)) запускает и анимацию, и запрос параллельно. Когда запрос при старте — плохая идея? В утилитах, которые открывают панель ради локальных действий: без сети приложение будет стоять в загрузке без нужды, и данные лучше тянуть по требованию. Отдельный вопрос — кэш: держать последние данные в модели и при перезагрузке показывать их сразу, помечая refresh, — пользователи прокрутки оценят, что позиция не прыгает к началу. Всё это не усложняет механизм: та же команда, то же сообщение, другая точка возврата. Заметьте только, что Init выполняется один раз за жизнь программы, поэтому периодическое обновление списка — не его работа: тикающий refresh делает команда-таймер, о которой дальше по курсу.

Получать данные научились — следующий шаг отдавать: форма, которая собирает логин и пароль и отправляет их на сервер через ту же команду с http.Post, — это следующий урок про фокус и формы. Пока запрос едет, экран должен жить: спиннер из шестого урока вешается на stateLoading за десять минут, а параллельный старт анимации и загрузки — Batch из седьмого. Проверяйте каркас на реальном API — публичные тестовые серверы вроде jsonplaceholder подходят идеально, но только локальный запуск покажет таймауты в действии. Когда загрузок станет много, а фабрики команд размножатся по файлам, им понадобится дисциплина структуры — до неё руки дойдут в уроке про тестирование TUI, где фиктивные ответы проверяют Update без сети. Обзор всего маршрута — на странице курса Bubble Tea.