Можно ли отказаться от StateObject?

Можно ли отказаться от StateObject в SwiftUI?

Да, отказаться от @StateObject в принципе возможно, но в подавляющем большинстве случаев это будет означать либо использование альтернативных инструментов, которые выполняют схожую роль, либо сознательный отказ от правильного управления жизненным циклом объекта, что приведет к проблемам в приложении. @StateObject — это не просто синтаксический сахар, а фундаментальная часть архитектуры данных SwiftUI, предназначенная для правильного владения и управления жизненным циклом observable object (наблюдаемого объекта).

Роль @StateObject и почему отказ от него проблематичен

@StateObject — это property wrapper, который выполняет две ключевые функции:

1. Владение (Ownership): View, объявляющая @StateObject, становится его владельцем. Это гарантирует, что объект будет существовать на протяжении всего жизненного цикла этой View и не будет уничтожен при её перерисовках.
2. Наблюдение (Observation): Он автоматически подписывает View на изменения в объекте (который должен соответствовать протоколу ObservableObject), чтобы при публикации изменений (через @Published или objectWillChange) View могла обновиться.

Попытка просто "отказаться" от него и использовать, например, обычное свойство, приведёт к критическим проблемам:

// ❌ НЕПРАВИЛЬНО: MyViewModel будет пересоздаваться при каждой перерисовке View
struct MyView: View {
    var viewModel = MyViewModel() // Создается заново каждый раз!

    var body: some View {
        Text(viewModel.title)
        Button("Update") { viewModel.updateTitle() }
        // Нажатие кнопки вызовет обновление внутри viewModel,
        // но View не будет знать об этом и не перерисуется.
    }
}

class MyViewModel: ObservableObject {
    @Published var title = "Hello"
    func updateTitle() { title = "Updated" }
}

Альтернативы @StateObject (которые, по сути, являются его "заменами" в разных контекстах)

Когда говорят об "отказе от @StateObject", обычно подразумевают использование других инструментов SwiftUI для управления данными. Вот основные альтернативы:

1. @ObservedObject: Используется, когда View не владеет объектом, а лишь наблюдает за ним, получая его извне (например, от родительской View). Это не отказ от StateObject, а его дополнение. Родительская View должна создать и хранить объект в @StateObject, а затем передать его дочерней.

   struct ParentView: View {
       @StateObject var viewModel = SharedViewModel() // Владение здесь
   
       var body: some View {
           ChildView(viewModel: viewModel) // Передача наблюдения
       }
   }
   
   struct ChildView: View {
       @ObservedObject var viewModel: SharedViewModel // Наблюдение здесь
   
       var body: some View {
           Text(viewModel.data)
       }
   }
   

2. @EnvironmentObject: Используется для "сквозного" доступа к общим данным, которые были помещены в окружение (environmentObject(_:)) на более высоком уровне иерархии View. Это удобно для глобальных или сильно вложенных зависимостей (например, AuthService, Router). Опять же, где-то выше по цепочке этот объект должен быть создан через @StateObject.

   class AppSettings: ObservableObject { @Published var isDarkMode = false }
   
   @main
   struct MyApp: App {
       @StateObject var settings = AppSettings() // Создание и владение
   
       var body: some Scene {
           WindowGroup {
               ContentView()
                   .environmentObject(settings) // Помещение в окружение
           }
       }
   }
   
   struct DeeplyNestedView: View {
       @EnvironmentObject var settings: AppSettings // Получение из окружения
   
       var body: some View {
           Toggle("Dark Mode", isOn: $settings.isDarkMode)
       }
   }
   

3. "Новая" архитектура данных с @Observable (iOS 17+): Начиная с iOS 17, SwiftUI представил макрос @Observable, который позволяет создавать наблюдаемые классы без явного соответствия протоколу ObservableObject. Для работы с такими объектами используется property wrapper @State для владения и @Bindable для создания привязок (Binding). Это самый современный и рекомендуемый способ, который во многих сценариях заменяет @StateObject/@ObservedObject.

   import Observation
   
   @Observable // Новый макрос вместо ObservableObject
   class NewViewModel {
       var title = "Hello" // @Published больше не нужен
       func updateTitle() { title = "Updated" }
   }
   
   struct MyView: View {
       @State private var viewModel = NewViewModel() // Владение через @State
   
       var body: some View {
           VStack {
               Text(viewModel.title) // Автоматическое наблюдение
               Button("Update") { viewModel.updateTitle() }
               // Для создания Binding (например, для TextField):
               TextField("Title", text: $viewModel.title)
               // Или используй @Bindable, если viewModel получен извне:
               // @Bindable var viewModel: NewViewModel
           }
       }
   }
   

Вывод: Что значит "отказаться"?

• Если цель — отказаться от использования конкретного property wrapper @StateObject в пользу более нового @Observable + @State, то да, это не только возможно, но и рекомендуется для проектов, таргетирующих iOS 17+.
• Если цель — отказаться от концепции владения View своим наблюдаемым источником данных, то нет, это архитектурная ошибка. Без механизма владения (@StateObject, @State для @Observable-класса) ваш источник данных будет нестабильным, что приведёт к потере состояния, неожиданным повторным созданиям объектов и багам в интерфейсе.

Таким образом, вы можете заменить @StateObject на @State для @Observable-классов как более современную альтернативу, но вы не можете отказаться от самого принципа, который он воплощает: гарантированного владения и управления жизненным циклом наблюдаемого объекта, привязанного к жизненному циклу View. Выбор инструмента зависит от версии iOS, которую вы поддерживаете, и архитектурных предпочтений, но необходимость в самом механизме — неизменна.