Определите владельца значения
Представим список покупок, в котором у каждого пункта есть признак выполнения. Строка показывает отметку, а заголовок — число оставшихся пунктов. Если строка и заголовок хранят независимые копии одних и тех же сведений, они могут разойтись после изменения. Поэтому нужно определить одно место, где находится актуальное значение. В SwiftUI локальное состояние представления часто оформляют через State, а дочернему представлению могут передать Binding — связь для чтения и изменения значения, которым владеет другой уровень. Если дочерний элемент только показывает информацию, двусторонняя связь ему не обязательно нужна. Выбор зависит от ответственности каждой части интерфейса.
Проследите изменение по шагам
В нашем учебном списке три пункта: бумага, карандаш и папка. Изначально ничего не отмечено, поэтому заголовок показывает три оставшихся покупки. Пользователь отмечает бумагу. Меняется соответствующее значение в данных, после чего строка и заголовок отражают новое состояние: отметка появилась, осталось два пункта. Важно не поддерживать вручную отдельный счётчик, если его можно вычислить из списка. Иначе возможна ошибка: строка уже отмечена, а число не уменьшилось. Производное значение лучше получать из исходных данных. Этот принцип не означает, что любое вычисление всегда выполняется одинаково: в сложных приложениях учитывают объём данных и производительность. Для маленького примера главное — ясность зависимости.
Не путайте состояние экрана с сохранением
Значение, которое существует во время работы интерфейса, не обязательно переживёт закрытие приложения. State не следует считать универсальным постоянным хранилищем. Если покупки должны сохраняться между запусками, нужен отдельно продуманный механизм хранения. Есть и другая граница: редактирование черновика. Допустим, пользователь открыл название пункта, изменил его, а затем нажал отмену. Если каждое введённое изменение сразу записывалось в основной список, отменять уже нечего. Для такого сценария может потребоваться отдельный временный текст и явное подтверждение. Поэтому перед реализацией полезно нарисовать не только экран, но и переходы: открыть, изменить, подтвердить, отменить. Правильная структура данных зависит от ожидаемого поведения, а не от количества используемых обёрток.
Попробуйте на практике
Нарисуйте модель списка покупок из трёх пунктов и диалог редактирования названия. Компьютер, аккаунт разработчика и установка инструментов не требуются.
- Запишите исходные данные: три названия и по одному признаку выполнения. Отдельно обозначьте вычисляемое число оставшихся пунктов.
- Покажите стрелкой, какая часть интерфейса меняет признак и какие части читают результат. Не создавайте вторую независимую копию списка.
- Проследите последовательность: отметить один пункт, открыть другое название, изменить черновик и отменить. Запишите итоговые значения.
- Повторите сценарий с подтверждением. Отметьте отдельным вопросом, что должно произойти после закрытия и повторного запуска приложения.
Как проверить результат. После отметки остаются две покупки. Отмена сохраняет прежнее название, подтверждение меняет его, а постоянное хранение не считается автоматически обеспеченным состоянием экрана.
Частые вопросы
Binding хранит ещё одну копию значения?
Он представляет связь с источником значения и позволяет читать или изменять его через эту связь. Независимая копия имела бы другую семантику и могла бы рассинхронизироваться.
Нужно ли сразу изучать все архитектурные подходы?
Для первого примера важнее понять владельца данных, производные значения и сценарии изменения. Более сложная архитектура полезна, когда решает конкретные задачи приложения, а не просто добавляет новые названия.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.