.task { } — co to jest, modyfikator async i ładowanie danych w View

Co to jest .task { } w SwiftUI

.task { } — to modyfikator View, który tworzy Task w kontekście async przy pojawieniu się View na ekranie. SwiftUI uruchamia przekazane zamknięcie w tle, podczas gdy główny wątek pozostaje wolny dla operacji UI. Gdy View znika, SwiftUI automatycznie anuluje Task poprzez mechanizm Structured Concurrency — gwarantuje to, że operacja asynchroniczna nie będzie kontynuowana po tym, jak jej wynik nie jest już nikomu potrzebny.

Według Apple — Swift Programming Language (2025), .task używa koncepcji Structured Concurrency, wprowadzonej w Swift 5.5. Każdy .task tworzy zadanie podrzędne w ramach zadania nadrzędnego View. Jeśli zadanie nadrzędne zostanie anulowane (View znika), wszystkie zadania podrzędne również są automatycznie anulowane. To radykalnie upraszcza zarządzanie cyklem życia operacji asynchronicznych w porównaniu z ręcznym przechowywaniem referencji do DispatchWorkItem lub AnyCancellable.

W przeciwieństwie do tradycyjnego podejścia z @State + ręcznym wywołaniem w .onAppear, .task nie wymaga przechowywania referencji do Task w celu późniejszego anulowania. SwiftUI robi to automatycznie, co zmniejsza ilość kodu boilerplate i eliminuje ryzyko zapomnienia o anulowaniu zadania.

struct ArticlesView: View {
    @State var articles: [Article] = []
    @State var error: Error?
    
    var body: some View {
        List(articles) { article in
            Text(article.title)
        }
        .task {
            do {
                articles = await APIClient().fetchArticles()
            } catch {
                self.error = error
            }
        }
    }
}

.task vs .onAppear: kluczowe różnice

Wielu programistów przyzwyczaiło się ładować dane w .onAppear, ale wraz z pojawieniem się async/await i .task to podejście stało się przestarzałe. .onAppear wykonuje kod synchronicznie — dla operacji asynchronicznych wewnątrz .onAppear trzeba opakować wywołanie w Task { } i ręcznie przechowywać referencję do niego w celu ewentualnego anulowania. .task robi to automatycznie.

.onAppear wciąż jest przydatny dla operacji synchronicznych — na przykład logowania lub początkowej konfiguracji UI. Ale do asynchronicznego ładowania danych, zapytań sieciowych, pracy z bazą danych lub systemem plików używaj .task. Jest to bezpieczniejsze i czystsze z punktu widzenia architektury.

// ❌ Starsze podejście: Task w .onAppear bez anulowania
var loadTask: Task<Void, Never>?
func body() { var body: some View { Text("") }
    .onAppear {
        loadTask = Task { await loadData() }
    }
    .onDisappear { loadTask?.cancel() }

// ✅ Nowoczesne podejście: .task zarządza anulowaniem
func body() { var body: some View { Text("") }
    .task { await loadData() }

.task(id:) — restart przy zmianie danych

Modyfikator .task(id:) przyjmuje dodatkowy parametr — identyfikator. Gdy wartość identyfikatora się zmienia, SwiftUI anuluje bieżące zadanie i uruchamia nowe z nowym identyfikatorem. Jest to idealne rozwiązanie dla ekranów, gdzie dane zależą od wybranego parametru — na przykład lista artykułów według kategorii lub szczegóły produktu według ID.

struct CategoryView: View {
    let categoryId: Int
    @State var items: [Item] = []
    
    var body: some View {
        List(items) { item in
            Text(item.name)
        }
        .task(id: categoryId) {
            await loadItems(for: categoryId)
        }
    }
    
    func loadItems(for id: Int) async {
        do {
            items = await APIClient().fetchItems(categoryId: id)
        } catch {
            // obsłuż błąd
        }
    }
}

Gdy categoryId się zmienia, SwiftUI anuluje poprzednie zapytanie i uruchamia nowe. Jest to szczególnie ważne przy szybkim przełączaniu kategorii — stare zapytania nie będą konkurować z nowymi o aktualizację stanu. Bez .task(id:) trzeba by ręcznie śledzić zmiany przez .onChange i ręcznie zarządzać Task.

Anulowanie zadań i sprawdzanie isCancelled

Chociaż .task automatycznie anuluje zadanie przy zniknięciu View, sama operacja asynchroniczna powinna kooperatywnie sprawdzać anulowanie. Swift używa kooperatywnego modelu anulowania — Task.cancel() nie zatrzymuje wykonania przymusowo, a jedynie ustawia flagę isCancelled. Kod wewnątrz zadania powinien okresowo sprawdzać tę flagę.

struct LoadingView: View {
    @State var progress: Double = 0
    
    var body: some View {
        ProgressView(value: progress)
            .task {
                for i in 0..<100 {
                    // Sprawdź anulowanie
                    try Task.checkCancellation()
                    
                    await Task.sleep(nanoseconds: 50_000_000)
                    progress = Double(i + 1) / 100.0
                }
            }
    }
}

Task.checkCancellation() rzuca CancellationError, jeśli zadanie zostało anulowane. To najprostszy sposób sprawdzenia — działa w każdym kontekście async. Alternatywa — ręczne sprawdzanie Task.isCancelled przed kosztownymi operacjami. Dla URLSession zapytania sieciowe są automatycznie anulowane przy anulowaniu zadania, ponieważ URLSession obsługuje Structured Concurrency od razu.

Praktyczne przykłady .task

.task nadaje się do wielu scenariuszy: od prostego ładowania JSON po złożone operacje równoległe z TaskGroup. Rozważmy trzy typowe przykłady użycia.

Ładowanie z obsługą błędów

struct ProfileView: View {
    @State var profile: Profile?
    @State var isLoading = true
    
    var body: some View {
        Group {
            if isLoading {
                ProgressView()
            } else if let profile {
                Text(profile.name)
            } else {
                Text("Nie udało się załadować")
            }
        }
        .task {
            defer { isLoading = false }
            do {
                profile = await APIClient().fetchProfile()
            } catch {
                // profil pozostaje nil
            }
        }
    }
}

Równoległe ładowanie z TaskGroup

struct DashboardView: View {
    @State var stats: DashboardStats?
    
    var body: some View {
        Text("Panel główny")
            .task {
                stats = await Task {
                    await withThrowingTaskGroup { group in
                        group.addTask { await API().fetchUsers() }
                        group.addTask { await API().fetchOrders() }
                        group.addTask { await API().fetchRevenue() }
                        
                        return DashboardStats(
                            users: try await group.next(),
                            orders: try await group.next(),
                            revenue: try await group.next()
                        )
                    }
                }.value
            }
    }
}

Typowe błędy z .task

Najczęstszym błędem jest mutacja właściwości UI wewnątrz .task bez przełączania na główny wątek. Chociaż SwiftUI automatycznie zwraca aktualizacje na główny wątek przy zmianie @State w kontekście async, bezpośrednie manipulacje elementami UIKit wewnątrz .task mogą spowodować crash.

• Zapomniałeś try/catch — .task nie obsługuje błędów automatycznie. Wszystkie funkcje rzucające wewnątrz muszą być opakowane w do/catch, w przeciwnym razie aplikacja ulegnie awarii.
• Race condition — jeśli kilka .task(id:) jest uruchomionych z różnymi id i aktualizuje ten sam stan, możliwe są wyścigi. Używaj oddzielnych właściwości dla różnych źródeł danych.
• Długie operacje synchroniczne — .task nie czyni kodu synchronicznego asynchronicznym. Jeśli wewnątrz .task jest ciężka praca synchroniczna, opakuj ją w Task.detached lub przenieś do osobnej metody async.
• Ignorowanie CancellationError — przy sprawdzaniu Task.checkCancellation() błąd CancellationError powinien być propagowany w górę, a nie tłumiony. Tłumienie anulowania może prowadzić do wycieków pamięci.

// ❌ Błąd: brak obsługi błędów
.task {
    let data = await fetchData() // awaria przy błędzie!
    items = data
}

// ✅ Prawidłowo: do/catch
.task {
    do {
        items = await fetchData()
    } catch {
        errorMessage = error.localizedDescription
    }
}