Декларативный подход SwiftUI

Главная идея SwiftUI: вы описываете, КАК интерфейс должен выглядеть для текущих данных, а не пошагово командуете, что нарисовать.

Суть урока: в декларативном UI интерфейс — это функция от состояния. Меняется состояние — SwiftUI сам пересчитывает и обновляет нужные части экрана. Вам не нужно вручную трогать элементы.

Чтобы прочувствовать разницу, сравним два мира. В императивном подходе (старый UIKit) вы создаёте элемент, а потом вручную меняете его при каждом событии: «возьми этот лейбл, установи ему текст, теперь перекрась». Вы отвечаете за каждый шаг и за синхронизацию состояния с экраном.

В декларативном SwiftUI вы описываете результат: «здесь текст, равный имени пользователя». Если имя меняется — текст обновляется сам. Вы описываете что, а как берёт на себя фреймворк:

struct CounterView: View {
    @State private var count = 0

    var body: some View {
        VStack {
            Text("Счёт: \(count)")        // зависит от count
            Button("Добавить") {
                count += 1                  // меняем состояние
            }
        }
    }
}

Здесь нет строчки «обнови текст». Мы лишь сказали, что Text зависит от count. Когда кнопка увеличивает count, SwiftUI заново вызывает body и обновляет именно тот текст, который изменился. Свойство body — это и есть функция, превращающая состояние в описание интерфейса.

СОСТОЯНИЕ           ФУНКЦИЯ body         ЭКРАН
 count = 0    -->   Text("Счёт: 0")   -->  [Счёт: 0]
   |  tap
   v
 count = 1    -->   Text("Счёт: 1")   -->  [Счёт: 1]

   вы меняете данные, SwiftUI перерисовывает сам

Попробуй сам ▶ — запусти код прямо в браузере (Pyodide). Здесь нет Swift, но логика та же, что под капотом мобильного кода:

# Декларативность как чистая функция: интерфейс = render(состояние).
def render(state):
    # описываем, ЧТО показать для данного состояния
    return [f"Счёт: {state['count']}", "[Кнопка: Добавить]"]

state = {'count': 0}
print(render(state))      # начальный экран

# 'нажали кнопку' -> поменяли состояние -> перерисовали
state['count'] += 1
print(render(state))      # SwiftUI делает это автоматически

Как работает под капотом

SwiftUI хранит лёгкое дерево описаний вью. При изменении состояния он повторно вызывает body, получает новое дерево и сравнивает его со старым (diffing). Меняются только те нативные элементы, что реально отличаются, — это эффективно. Поэтому вью должно быть идемпотентным: для одного и того же состояния body обязан выдавать один и тот же результат, без побочных эффектов. Никогда не меняйте состояние прямо внутри body.

Частые ошибки

Пытаться вручную обновить вью. В SwiftUI вы меняете данные, а не элементы экрана.
Делать побочные эффекты в body. body должен только описывать интерфейс, а не загружать данные или менять состояние.
Мыслить категориями UIKit. Привычка «найти элемент и изменить» мешает освоить декларативность.

Best practices

Считайте body чистой функцией от состояния — без сюрпризов и побочных эффектов.
Меняйте состояние, а не вью; UI обновится сам.
Дробите интерфейс на маленькие вью — их проще читать и переиспользовать.

Итоги. SwiftUI декларативен: интерфейс — это функция от состояния. Вы описываете желаемый результат, а фреймворк сам обновляет экран при изменении данных. Этот сдвиг мышления — главный порог входа, и, преодолев его, вы будете писать UI быстрее и с меньшим числом багов.

Шире контекста

Сдвиг от императивного к декларативному мышлению — самый трудный, но и самый важный порог в освоении SwiftUI, особенно для тех, кто раньше работал с UIKit или другими императивными фреймворками. Там вы держали ссылки на элементы и вручную синхронизировали их с данными: «данные поменялись — не забудь обновить лейбл, перекрасить кнопку, спрятать спиннер». Каждая забытая синхронизация была багом. В декларативном мире эта целая категория ошибок просто исчезает: вы описываете, как интерфейс выглядит для данных, а связь «данные → экран» поддерживает фреймворк. Ваша ответственность сужается до одного — корректно менять состояние. Это перекликается с идеями из мира веба (React и подобные библиотеки) и отражает общую индустриальную тенденцию. Чем раньше вы начнёте думать «интерфейс — это функция от состояния», тем естественнее лягут все последующие темы: @State, @Binding, @Observable и однонаправленный поток данных — это лишь разные грани одного и того же принципа.