Привязка данных (binding)

Восемнадцать уроков подряд ты доставал данные в интерфейс по личному распоряжению: SetText в обработчике кнопки, RefreshItem после удаления записи, обновление метки после каждого клика. Пока источник один и обработчиков два, схема живёт; но когда значений становится десятки, а менять их нужно из разных мест — из меню четырнадцатого урока, из диалогов тринадцатого, из фоновых задач — ручная синхронизация начинает пропускать обновления, и интерфейс врёт. Пакет fyne.io/fyne/v2/data/binding решает задачу архитектурно. Запрос «fyne binding» — это источники данных, которые сами сообщают подписчикам об изменениях: значение перестаёт быть безликой переменной и становится объектом — DataItem с методами AddListener и RemoveListener. Над DataItem построены типизированные интерфейсы: binding.String с парой Get() (string, error) и Set(string) error, а рядом binding.Float, binding.Bool и binding.Int. Источник создаётся фабрикой: binding.NewString() даёт пустую строку, NewFloat(), NewBool() и NewInt() — нули; начального значения в конструкторе нет, заполнение делается через Set. Заметь контракт ошибок: и Get, и Set возвращают error. У фабричного источника она всегда nil — таково правило игры; но у источников, привязанных к внешнему миру, ошибка настоящая, и код честно получает пару (v, err), а не падает на месте. Третья опора — уведомление: после каждого Set источник рассылает слушателям сигнал DataChanged, и каждый подписчик перечитывает значение через Get. Виджеты уже умеют быть подписчиками: метод Bind есть у Entry, Label, Check, Slider, ProgressBar и Select. Разберём первый пример.

Семейство источников покрывает все базовые типы интерфейса, и у каждого виджета есть свой естественный напарник. Текстовые — Entry и MultiLineEntry, а также Label — работают с binding.String. widget.Check и widget.Select нуждаются в булевом и строковом значении: Check привязывается к binding.Bool, галочка включена или выключена; Select хранит выбранный вариант как binding.String. Числа — царство binding.Float: Slider и ProgressBar обоих направлений привязываются к нему, поэтому громкость из ползунка и её отражение в прогресс-баре — это один источник и два Bind. Для целых счётчиков есть binding.Int, хотя на практике Float часто удобнее из-за прогресс-баров. Метод Bind принимает источник подходящего типа, компилятор не даст привязать Bool к Slider — типы защищают на этапе сборки. Противоположность — Unbind(): отвязывает виджет от источника и сбрасывает подписку; он обязателен при переиспользовании шаблонных элементов, о чём будет отдельный разговор ближе к концу урока. В англоязычной документации весь этот подход зовут fyne data binding: данные — единственный источник истины, виджеты — только отображение. Отсюда практическое правило перехода: если в коде появилась связка «обработчик меняет переменную и вручную обновляет метку», это кандидат на источник плюс Bind. Пять лет назад такие связки были нормой — в этом курсе они жили до девятого урока включительно; сегодня замени их привязкой, и класс рассинхронизации исчезнет как вид. Осталось показать связку Check-Slider-ProgressBar в сборе.

Механизм подписки доступен и без виджетов — иногда нужно реагировать на изменение значением, а не картинкой: писать лог, пересчитывать итоги, дёргать сетевой запрос. Для этого есть интерфейс DataListener с единственным методом DataChanged и удобный конструктор binding.NewDataListener(func()) — он заворачивает твой колбэк в готового слушателя. Подключение — AddListener на источнике, отключение — RemoveListener. Помни две детали. Первая: подписка немедленно синхронизируется — предсказание выше показывало, что колбэк срабатывает уже при AddListener, поэтому не полагайся в нём на то, что «изменения ещё не было». Вторая: снимай слушателя, когда он больше не нужен. Источник держит ссылку на каждого подписчика; слушатель, привязанный к источнику с долгой жизнью, переживёт свой экран и будет выполняться впустую — классическая утечка замыканий. Практическое правило: кто создал слушателя для экрана, тот и снимает его при закрытии; в простых приложениях с одним окном этим можно пренебречь, в многоэкранных — нет. Порядок доставки не гарантирован: источник обходит подписчиков в порядке подписки, но строить логику на строгой очередности — хрупкое решение; если один слушатель должен увидеть результат другого, объединяй их в один колбэк. И последнее: колбэк выполняется в той горутине, где случился Set. Об этом — жёлтая рамка ниже и двадцатый урок.

Не всегда значение рождается внутри источника: иногда оно уже живёт в поле твоей структуры, и хочется привязать интерфейс к нему, не переписывая модель. Для этого есть семейство Bind: binding.BindString(&myField) возвращает ExternalString — источник, у которого Set пишет и в хранилище, и в твою переменную, а метод Reload() перечитывает внешнее значение и рассылает уведомления, если данные поменялись извне. Аналогично устроены BindFloat, BindBool и BindInt с указателями на float64, bool и int. Правило одно: переменная обязана жить достаточно долго — указатель на локальную переменную функции приведёт к висячей привязке. Второй инструмент — преобразования. binding.StringToString(func(s string) string) даёт источник-надстройку: он слушает исходный и выдаёт преобразованное значение; пример с громкостью показывал FloatToString для процентов. Если преобразование должно работать в обе стороны — из отображения в данные при правке поля — бери FloatToStringWithReverse и братьев: конструктор принимает две функции, прямую и обратную, и привязанный Entry пишет в данные уже разобранное значение. Классика — температура в обе стороны или форматирование дат. Третий инструмент — коллекции: binding.NewUntypedList() создаёт источник списка, Append и Remove меняют состав, а widget.List.Bind подключает виртуализированный список из десятого урока к данным — элементы списка получают свои мини-источники, и RefreshItem становится не нужен: изменение элемента обновляет только его строку. Для таблиц одиннадцатого урока есть табличные привязки — механика та же, детали — в документации пакета.

Главный подарок привязки — не экономия на SetText, а дисциплина состояния. Одна истина: значение живёт в источнике, и виджет — лишь окно в него; два места хранения одного значения гарантированно разъедутся, вопрос только когда. Практика: собирай источники в структуру состояния приложения — App struct с полями-привязками создаётся при старте и передаётся экранам; обработчики меняют источники, экраны подписаны, и новая фича не требует ревизии всех старых обработчиков. Не дублируй: если текст поля уже в binding.String, не храни копию в переменной «на всякий случай» — читай Get в момент нужды. Следи за переиспользованием: в шаблоне элемента List из десятого урока виджет один, а значений много — перед привязкой нового значения зови Unbind, иначе подписка от прошлой строки продолжит писать в свежие данные, и список начнёт путать строки под прокруткой. Это самый частый баг новичка в коллекциях с привязкой. Разумно делить: не превращай всё подряд в источники — локальная переменная внутри обработчика не заслуживает DataItem; привязка окупается там, где значение видно более чем в одном месте или меняется более чем из одного места. Помни про ошибки: Get возвращает пару, и источники, привязанные к внешнему миру, вправе ответить не-nil — обрабатывай хотя бы до уровня «показать ShowError из тринадцатого урока». Наконец, мости уровни: доменная модель пусть остаётся обычными структурами, а источники — тонким слоем между моделью и экраном; BindString-семейство как раз для этого.

Теперь данные текут: поле пишет в источник, подписчики обновляются сами, слушатели логируют каждое изменение. Но поток бесполезен, если в нём мусор — «abc» в поле возраста доедет до источника так же честно, как «42». Опора урока — девятый с Entry и его событиями, десятый с шаблонами списка и Unbind, второй с каркасом запуска. Следующая тема — валидация ввода: встроенные валидаторы Entry, свои правила func(string) error, красная рамка и блокировка Submit, пока данные не стали съедобными; привязка и валидация работают в паре — проверенное значение заслуживает права попасть в источник. Домашнее задание соберёт панель счётчика на одном Float с тремя виджетами и слушателем-логгером. Полный маршрут — на странице курса Fyne.