@StateObject: какво е, създаване и управление на ObservableObject

Какво е @StateObject в SwiftUI

@StateObject е property wrapper, въведен в iOS 14, който позволява на View да създава и притежава екземпляр на клас, съответстващ на протокола ObservableObject. За разлика от @State, който работи със стойностни типове (структури), @StateObject е предназначен за референтни типове — класове, които могат да уведомяват SwiftUI за промени в своите свойства.

Когато View използва @StateObject var viewModel: MyViewModel, SwiftUI автоматично създава екземпляр на MyViewModel при първото показване на View и го съхранява в специално хранилище на framework-а. При всяка актуализация на View (например при промяна на родителското състояние), SwiftUI не пресъздава обекта — използва съществуващия екземпляр, докато View не бъде премахнато от йерархията.

Според Apple WWDC Session 10137 (2024), @StateObject решава проблема със загубата на данни при преизграждане на View, който съществуваше в iOS 13, когато разработчиците трябваше да създават ObservableObject в родителското View и да го предават чрез инициализатора. Това водеше до дублиране на код и риск от случайно пресъздаване на обекта.

import SwiftUI

class CounterViewModel: ObservableObject {
    @Published var count: Int = 0
    
    func increment() {
        count += 1
    }
}

struct CounterView: View {
    @StateObject var viewModel = CounterViewModel()
    
    var body: some View {
        VStack {
            Text("Брой: \(viewModel.count)")
            Button("Увеличи", action: viewModel.increment)
        }
    }
}

Как работи @StateObject

Механизмът на @StateObject се основава на интеграцията на SwiftUI с framework-а Combine. Когато ObservableObject маркира своите свойства с атрибута @Published, SwiftUI автоматично се абонира за промени чрез publisher-а, вграден в протокола ObservableObject. При промяна на публикувано свойство, обектът изпраща сигнал чрез objectWillChange publisher, което задейства прерисуване на всички View, наблюдаващи този обект.

SwiftUI съхранява екземпляра на ObservableObject в специално хранилище, обвързано с конкретен екземпляр на View. Това хранилище се създава веднъж при първото рендиране и съществува до унищожаването на View. Точно поради тази причина @StateObject гарантира стабилността на референцията към обекта — SwiftUI управлява паметта автоматично, без да разчита на инициализатора на View.

Според objc.io — Thinking in SwiftUI (2025), вътрешната имплементация на @StateObject използва механизъм, подобен на @State, но за референтни типове: SwiftUI създава boxing обвивка около обекта и управлява жизнения му цикъл чрез собствен алокатор, оптимизиран за чести преизграждания на йерархията на View.

Жизнен цикъл на @StateObject

• Създаване — при първото появяване на View на екрана, SwiftUI извиква инициализатора на обекта и запазва референцията.
• Преизграждане — при актуализиране на родителското View, обектът не се пресъздава, използва се съществуващият екземпляр.
• Унищожаване — когато View напусне екрана и бъде премахнато от йерархията, SwiftUI извиква deinit на обекта.

@StateObject срещу @ObservedObject: ключови разлики

Основната разлика между @StateObject и @ObservedObject е кой притежава обекта. @StateObject създава и съхранява обекта — той е собственик. @ObservedObject само наблюдава обект, който е създаден някъде другаде и предаден чрез инициализатор или свойство.

Правилото е просто: ако View създава ObservableObject — използвайте @StateObject. Ако View само получава вече готов обект от родителя — използвайте @ObservedObject. Нарушаването на това правило води или до загуба на данни (ако използвате @ObservedObject за притежание), или до прекомерно създаване на обекти (ако използвате @StateObject за наблюдение).

Кога да използваме @StateObject

@StateObject трябва да се използва в онези View, които са източник на истина за определен набор от данни. Типични сценарии включват екрани със собствен view model, коренови екрани на навигационни стекове и модални презентации, управляващи собствено състояние.

• Екран с view model — всеки екран, който управлява собствени данни и логика, трябва да създава своя view model чрез @StateObject.
• Коренов View — в йерархията на NavigationStack или TabView, кореновият елемент създава данни, а дъщерните ги получават чрез @ObservedObject.
• Модални прозорци — .sheet и .fullScreenCover често изискват собствен @StateObject за управление на формуляр или процес.
• Списък с редактиране — всеки ред от списък, съдържащ формуляр за редактиране, трябва да има собствен @StateObject.

struct ProfileView: View {
    @StateObject var viewModel = ProfileViewModel()
    
    var body: some View {
        NavigationStack {
            Form {
                TextField("Name", text: $viewModel.name)
                TextField("Email", text: $viewModel.email)
                Button("Запази") {
                    viewModel.saveProfile()
                }
            }
            .navigationTitle("Profile")
        }
    }
}

Инициализация на @StateObject с параметри

Инициализацията на @StateObject с параметри изисква специален синтаксис, тъй като SwiftUI управлява създаването на обекта независимо. Не можете просто да предадете параметри на инициализатора — трябва да използвате escaping затваряне или отделен метод за създаване.

Според Swift by Sundell (2024), най-чистият метод е използването на фабричен метод или затваряне, което SwiftUI ще извика при първото създаване на обекта. Алтернативен подход — инициализирайте ObservableObject в родителското View и го предайте чрез @StateObject, използвайки стандартния инициализатор.

class UserViewModel: ObservableObject {
    @Published var user: User
    
    init(user: User) {
        self.user = user
    }
}

struct UserDetailView: View {
    @StateObject var viewModel: UserViewModel
    
    init(user: User) {
        _viewModel = StateObject(wrappedValue: UserViewModel(user: user))
    }
    
    var body: some View {
        Text(viewModel.user.name)
    }
}

Важно е да запомните, че инициализаторът на View с @StateObject трябва да използва долна черта пред името на свойството (_viewModel) за достъп до самия property wrapper, а не до неговата стойност. Това е стандартен модел в Swift за работа с property wrappers в инициализатори.

Типични грешки с @StateObject

Най-често срещаната грешка е използването на @ObservedObject вместо @StateObject за View, което трябва да притежава обекта. В този случай при всяко преизграждане на родителя, обектът ще бъде пресъздаден, което води до загуба на всички натрупани данни. Тази грешка е особено коварна в сложни йерархии с NavigationStack или TabView.

• Загуба на данни при навигация — ако дъщерен екран използва @ObservedObject за собствен view model, при връщане и повторно отваряне данните ще бъдат нулирани.
• Изтичане на памет — създаването на @StateObject в родителско View, което никога не се премахва, може да доведе до натрупване на обекти, ако всеки дъщерен екран също създава @StateObject без контрол.
• Дублиране на обекти — предаването на един ObservableObject на няколко @StateObject в различни View създава няколко независими екземпляра, които не се синхронизират помежду си.

За да избегнете тези проблеми, следвайте простото правило: един @StateObject на източник на истина. Ако данните трябва да бъдат споделени между няколко екрана — създайте @StateObject веднъж в кореновото View и го предавайте чрез @ObservedObject или @EnvironmentObject на дъщерните елементи.

// ❌ Грешно: @ObservedObject за притежаване на обект
struct BadView: View {
    @ObservedObject var vm = ViewModel() // ще бъде пресъздаден при всяка актуализация!
}

// ✅ Правилно: @StateObject за притежаване
struct GoodView: View {
    @StateObject var vm = ViewModel() // създаден веднъж за живота на View
}