A Day in the Life of a SwiftUI View

Chris Eidhof раскрывает mental model SwiftUI, показыя, как наш код превращается в ephemeral view tree и в персистентный render tree — AttributeGraph. Chris подробно объясняет, как @State интегрируется в граф, оптимизирует layout и что происходит при каждом вызове body.

https://www.youtube.com/watch?v=MRY3UCUVv98
https://www.youtube.com/watch?v=MRY3UCUVv98
https://www.youtube.com/watch?v=MRY3UCUVv98

> Текстовая версия доклада
> Похожая статейка в ноушен
> Подробно про AttributeGraph в ноушен

#weak_let #swift #concurrency

Раньше weak можно было только с var, и из-за этого классы и замыкания с такими ссылками не были Sendable, но с принятием этого проползола можно будет объявлять слабые ссылки с let, а не только с var.

Зачем это нужно?
- Убирает лишнюю мутируемость, weak let не мешает проверкам на безопасность в конкурентных контекстах.
- Закрывает брешь в sendability: классы и @Sendable-замыкания с weak let становятся полностью безопасными.

Про мотивацию
1. weak var считался мутируемым, потому что при деинициализации объекта ссылка сбрасывалась в nil.
2. На самом деле это не "мутация" значения, а просто особенность weak ref.
3. Теперь weak let отражает именно эту логику – неизменяемая слабая ссылка, которая по-прежнему может стать nil.

Прочитать подробнее и посмотреть можно здесь: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0481-weak-let.md

final class ContentViewModel: ObservableObject {
    @Published var text = "Hello @StateObject"
    
    init() {
        print("ViewModel init")
    }
    
    deinit {
        print("ViewModel deinit")
    }
}

struct ContentView: View {
    @StateObject private var viewModel: ContentViewModel
    
    init(viewModel: ContentViewModel) {
        _viewModel = StateObject(wrappedValue: viewModel)
        
        print("ContentView init")
    }
    
    var body: some View {
        Text(viewModel.text)
    }
}

struct RootView: View {
    @State private var isOn = false
    
    var body: some View {
        VStack(spacing: 20) {
            ContentView(viewModel: ContentViewModel())
            
            if isOn { Text("is on") }
            
            Button("Trigger") { isOn.toggle() }
        }
    }
}

Есть ли у этого кода проблема связанная с объявлением StateObject? Опрос ниже

Выполнение асинхронных задач в SwiftUI

Начиная с iOS 14 вместо Task {…} в onAppear начинаем юзать встроенный модификатор .task – он сам создаёт и отменяет задачу вместе с жизненным циклом View:

Text("Привет, мир!")
  .task {              // ✅ запускается при появлении и отменяется при уходе
    await loadData()
  }

Но зачем так делать?
- Не надо городить Task вручную и переживать об отмене.
- Внутри .task {} у тебя сразу async-контекст – можно вызывать await напрямик.
- Логика асинхронки отделена от onAppear и проще читается.

Но это ещё не всё. Если нужна реакция на изменения, например ты стал что-то вводить, то ты можешь вызывать конструктор с id:

.searchable(text: $query)
.task(id: query) {    // каждый раз новый `query` – новая задача
  results = await fetch(query)
}

Теперь при изменении query предыдущая задача отменяется автоматически. Но и это ещё не все!

Ты можешь управлять приоритетом. По умолчанию приоритет – .userInitiated, но можно указать свой и для этого можно взять соответствующий конструктор:

.task(priority: .background) {
  await cleanupCache()
}

Используй модификатор .task, чтобы SwiftUI сам заботился о запуске и отмене твоих async-задач!

Подскажите пожалуйста, мы такое асуждаем или не асуждаем?

👍- асуждаем
👎- не асуждаем

https://ilovehackit.ru

#concurrency #async_await

Мало ли, пригодится!

Различие между наследование флага и автоматической отмены

Когда погружаешься в изучение structured concurrency, то можно упустить или запамятовать некоторые детали, а они бывают важными.

Так например есть разница между structured и unstructured tasks. И здесь даже можно спутаться, что есть structured, что есть unstructured... Но Apple отетила на этот вопрос твёрдо и чётко.

Структурированная конкурентность требует:
1. Scoped lifetime: дочерние задачи не могут пережить родительскую задачу.
2. Автоматическое ожидание: родитель должен дождаться всех дочерних задач перед завершением.
3. Fail-fast behavior: ошибки в дочерних задачах распространяются на родительскую.
4. Строгая иерархия parent-child: четкие отношения для распространения отмены и приоритета.

И здесь мы можешь заметить, что Task нарушает. А чтобы проверить, достаточно запустить и проверить:

func demonstrateUnstructuredTaskCancellation() async {
    print("🔵 Демонстрация Task {} - unstructured")
    
    let parentTask = Task {
        print("👨 Parent task начала работу")
        
        let childTask = Task {
            print("👶 Child task начала работу")
            
            // Проверяем отмену каждую секунду
            for i in 1...5 {
                if Task.isCancelled {
                    print("👶 Child обнаружила отмену на итерации \(i)")
                    return "Child завершилась по отмене"
                }
                
                print("👶 Child работает... итерация \(i)")
                try? await Task.sleep(nanoseconds: 1_000_000_000)
            }
            
            print("👶 Child завершила всю работу")
            return "Child успешно завершилась"
        }
        
        // Ждем немного и отменяем parent
        try? await Task.sleep(nanoseconds: 2_500_000_000)
        print("👨 Parent отменяется!")
        
        // Получаем результат child
        let result = await childTask.value
        print("👨 Parent получил результат: \(result)")
        
        return "Parent завершен"
    }
    
    // Отменяем parent task через 2.5 секунды
    parentTask.cancel()
    
    let finalResult = await parentTask.value
    print("🔵 Финальный результат: \(finalResult)")
    print("🔵 Обратите внимание: child task продолжила работу после отмены parent!\n")
}

// Запуск примера
await demonstrateUnstructuredTaskCancellation()

И мы увидим, что это не одно и тоже как если бы мы поступили с представителем structured tasks - withThrowingTaskGroup:

func demonstrateStructuredTaskCancellation() async {
    print("🟢 Демонстрация TaskGroup - structured")

    do {
        try await withThrowingTaskGroup(of: String.self) { group in
            print("👨 TaskGroup начала работу")

            // Запускаем три дочерние задачи
            for i in 1...3 {
                group.addTask {
                    print("👶 задача \(i) начала работу")
                    
                    for j in 1...5 {
                        try Task.checkCancellation()             // бросит CancellationError, если отменена
                        print("👶 задача \(i) итерация \(j)")
                        try await Task.sleep(nanoseconds: 1_000_000_000)
                    }
                    print("👶 задача \(i) завершилась")
                    return "задача \(i) успех"
                }
            }

            // Ждём 2.5 секунды в этой же области и отменяем группу
            try await Task.sleep(nanoseconds: 2_500_000_000)
            print("👨 TaskGroup отменяет все задачи!")
            group.cancelAll()

            // Сбор завершённых результатов
            var results: [String] = []
            for try await result in group {
                results.append(result)
                print("👨 Получен результат: \(result)")
            }
            print("👨 TaskGroup завершена. Всего результатов: \(results.count)")
        }
    } catch {
        print("🟢 TaskGroup завершилась с ошибкой: \(error)")
    }
    
    print("\n🟢 Все дочерние задачи в группе гарантированно либо отработали, либо были отменены.")
}

// Запуск примера
await demonstrateStructuredTaskCancellation()

Вот такой, небольшой, но интересный нюанс между наследованием флага отмены и автоматической отменой.

Swift Server Side Meetup #5

Да-да, движется по-немногоу. Прям как и сам язык swift в серверную разработку. Конечно свифту ещё далеко, но для тех кто на приколе серверной части для свита - рекомендую.

https://www.youtube.com/watch?v=0JrLkHgZa-k