@ViewBuilder: какво е, result builder за View в SwiftUI

Какво е @ViewBuilder в SwiftUI?

@ViewBuilder — е анотация, която имплементира модела result builder (SE-0289), позволяваща на SwiftUI да събира няколко View в една композиция с помощта на декларативен синтаксис. Тя автоматично обвива множество изрази, условни конструкции и опционални стойности в съответните типове: TupleView, ConditionalContent, OptionalContent.

Преди появата на result builder, разработчиците трябваше ръчно да обвиват елементите в VStack или HStack, а за условна логика да използват тернарни оператори или фабрични методи. @ViewBuilder направи синтаксиса на SwiftUI кратък и четим, позволявайки писане на код, който изглежда като обикновен Swift с if/else и цикли.

Според Swift Evolution SE-0289, result builders са общ механизъм, който не е обвързан с SwiftUI. @ViewBuilder е една от имплементациите на този механизъм, заедно с @StringBuilder за изграждане на низове и библиотечни имплементации за други DSL. В SwiftUI @ViewBuilder се използва не само за body, но и за параметрите-затваряния на контейнери (VStack, HStack, ZStack, List).

Разлика от императивния подход

В императивния UIKit вие императивно създавате UIView, конфигурирате свойствата му и го добавяте към йерархията чрез addSubview. В SwiftUI с @ViewBuilder вие декларативно описвате кои View трябва да бъдат показани, а SwiftUI сам управлява създаването, актуализирането и изтриването на елементи въз основа на промени в състоянието.

Как работи @ViewBuilder: result builder

Result builder — е механизъм на Swift, който преобразува последователност от изрази в една съставна стойност чрез статични методи buildBlock, buildOptional, buildEither и други. Когато компилаторът види анотацията @ViewBuilder, той автоматично прилага тези методи към блока код по време на компилация.

@resultBuilder
struct ViewBuilder {
    static func buildBlock<C0, C1>(_ c0: C0, _ c1: C1) -> TupleView<(C0, C1)>
    static func buildIf<C>(_ c: C?) -> C?
    static func buildEither<T, F>(first: T) -> ConditionalContent<T, F>
    static func buildEither<T, F>(second: F) -> ConditionalContent<T, F>
}

buildBlock приема от 1 до 10 израза и връща TupleView. Всяка арност (брой изрази) има свое собствено претоварване на buildBlock: от buildBlock<C0> до buildBlock<C0, C1, ..., C9>. Именно затова броят на елементите в един @ViewBuilder блок е ограничен до 10.

buildEither (first/second) обработва if/else конструкции. Всеки клон се предава на съответния метод и резултатът се обвива в ConditionalContent — тип, който скрива конкретните типове на клоновете и предоставя унифициран интерфейс за SwiftUI.

Неявна работа на @ViewBuilder

В SwiftUI свойството body вече е неявно анотирано с @ViewBuilder — не виждате тази анотация в кода, но компилаторът я прилага автоматично. Въпреки това, за потребителски свойства, които връщат няколко View, или за параметри-затваряния, анотацията трябва да бъде изрично посочена.

Ограничения на @ViewBuilder и как да ги заобиколите

Ограничение 1 — 10 елемента в блок. Това е най-известното ограничение на @ViewBuilder. Ако трябва да покажете повече от 10 елемента на едно ниво, компилаторът ще даде грешка. Можете да го заобиколите чрез Group, ForEach, List или разделяне на подкомпоненти. Group не добавя визуално влагане, но всеки Group се брои като един елемент.

struct ManyElementsView: View {
    var body: some View {
        Group {
            Text("1"); Text("2"); Text("3")
            Text("4"); Text("5"); Text("6")
            Text("7"); Text("8"); Text("9")
        }
        Group {
            Text("10"); Text("11"); Text("12")
        }
    }
}

Ограничение 2 — липса на поддръжка за някои конструкции. @ViewBuilder не поддържа do/catch, guard, for-in (без ForEach) и други управляващи конструкции. За цикли използвайте ForEach с идентифицируеми данни. За обработка на грешки използвайте отделни View, приемащи Result или опционални стойности.

Ограничение 3 — трудност при отстраняване на грешки. При грешки в @ViewBuilder компилаторът генерира многословни съобщения, в които е трудно да се намери основната причина. Типични проблеми: несъответствие на типове в if/else клонове, надвишаване на лимита от 10 елемента или липса на необходимото претоварване на buildBlock.

Модели на използване на @ViewBuilder

Модел 1: условно показване чрез if/else. Най-честият сценарий за използване на @ViewBuilder. Позволява показване на различни View в зависимост от състоянието без използване на тернарни оператори или фабрични методи.

struct StatusView: View {
    var status: LoadStatus

    @ViewBuilder
    var body: some View {
        switch status {
        case .loading:
            ProgressView("Loading...")
        case .loaded(let data):
            DataView(data: data)
        case .error(let message):
            ErrorView(message: message)
        }
    }
}

Модел 2: @ViewBuilder в параметри на функции и инициализатори. Използва се за създаване на многократно използваеми контейнери, които приемат дъщерни View чрез затваряне. Това е стандартен модел за библиотеки и UI компоненти.

struct SectionCard<Content: View>: View {
    let title: String
    @ViewBuilder let content: Content

    var body: some View {
        VStack(alignment: .leading) {
            Text(title).font(.headline)
            content
        }
        .padding()
        .background(Color.gray.opacity(0.1))
        .cornerRadius(12)
    }
}

Модел 3: композиция с ForEach. @ViewBuilder работи правилно с ForEach, позволявайки динамично генериране на елементи от масив от данни. Всеки ForEach елемент се брои като един израз в контекста на @ViewBuilder.

Създаване на персонализиран ViewBuilder за многократно използваеми компоненти

Персонализиран ViewBuilder — е потребителска функция или свойство, анотирано с @ViewBuilder, което връща some View. Такива функции позволяват капсулиране на сложна логика за показване и повторното й използване в различни части на приложението.

struct FormRow<Content: View>: View {
    let label: String
    @ViewBuilder let content: Content

    var body: some View {
        HStack {
            Text(label)
                .frame(width: 120, alignment: .trailing)
            content
        }
    }
}

// Употреба:
FormRow(label: "Name") {
    TextField("Enter name", text: $name)
}

FormRow(label: "Gender") {
    Picker("Select", selection: $gender) {
        Text("Мъж").tag(Gender.male)
        Text("Жена").tag(Gender.female)
    }
}

Важно правило: персонализирана функция с @ViewBuilder трябва да връща some View, а не конкретен тип или протокол View. Само opaque тип позволява скриване на конкретната имплементация и запазване на гъвкавостта на композицията.

Производителност: персонализираните @ViewBuilder функции не добавят допълнителен разход в сравнение с директния код в body. Компилаторът вгражда извикванията и оптимизира резултантния код. Разделянето на body на @ViewBuilder функции подобрява четимостта без загуба на производителност.