.task { } — mi ez, async módosító és adatbetöltés View-ban

Mi a .task { } a SwiftUI-ban

.task { } — egy View módosító, amely Task-ot hoz létre async kontextusban, amikor a View megjelenik a képernyőn. A SwiftUI elindítja a megadott closure-t a háttérben, miközben a fő szál szabad marad az UI műveletek számára. Amikor a View eltűnik, a SwiftUI automatikusan megszakítja a Task-ot a Structured Concurrency mechanizmusán keresztül — ez garantálja, hogy az aszinkron művelet nem folytatódik, miután az eredményére már nincs szükség.

Az Apple — Swift Programming Language (2025) szerint a .task a Structured Concurrency koncepciót használja, amely a Swift 5.5-ben került bevezetésre. Minden .task létrehoz egy gyermekfeladatot a szülő View feladatának keretében. Ha a szülő feladat megszakad (a View eltűnik), az összes gyermekfeladat is automatikusan megszakad. Ez radikálisan leegyszerűsíti az aszinkron műveletek életciklusának kezelését a DispatchWorkItem vagy AnyCancellable referenciák manuális tárolásához képest.

Ellentétben a hagyományos @State + manuális hívás .onAppear-ban megközelítéssel, a .task nem igényli a Task referenciájának tárolását későbbi megszakításhoz. A SwiftUI ezt automatikusan teszi, ami csökkenti a boilerplate kód mennyiségét és kiküszöböli a feladat megszakításának elfelejtéséből eredő kockázatot.

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: főbb különbségek

Sok fejlesztő megszokta, hogy adatokat tölt be a .onAppear-ben, de az async/await és a .task megjelenésével ez a megközelítés elavult. A .onAppear szinkron módon hajtja végre a kódot — az aszinkron műveletekhez a .onAppear-en belül a hívást Task { }-be kell csomagolni, és manuálisan tárolni egy referenciát a lehetséges megszakításhoz. A .task ezt automatikusan teszi.

A .onAppear továbbra is hasznos szinkron műveletekhez — például naplózáshoz vagy az UI kezdeti konfigurálásához. De aszinkron adatbetöltéshez, hálózati kérésekhez, adatbázis- vagy fájlrendszer-műveletekhez használd a .task-ot. Ez architektúrális szempontból biztonságosabb és tisztább.

// ❌ Régi megközelítés: Task a .onAppear-ben megszakítás nélkül
var loadTask: Task<Void, Never>?
func body() { var body: some View { Text("") }
    .onAppear {
        loadTask = Task { await loadData() }
    }
    .onDisappear { loadTask?.cancel() }

// ✅ Modern megközelítés: .task kezeli a megszakítást
func body() { var body: some View { Text("") }
    .task { await loadData() }

.task(id:) — újraindítás adatváltozáskor

A .task(id:) módosító egy további paramétert — egy azonosítót — fogad. Amikor az azonosító értéke megváltozik, a SwiftUI megszakítja az aktuális feladatot, és újat indít az új azonosítóval. Ez ideális azokhoz a képernyőkhöz, ahol az adatok a kiválasztott paramétertől függenek — például cikklista kategória szerint vagy termékrészletek ID alapján.

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 {
            // hiba kezelése
        }
    }
}

Amikor a categoryId megváltozik, a SwiftUI megszakítja az előző kérést, és újat indít. Ez különösen fontos a kategóriák gyors váltogatásakor — a régi kérések nem versenyeznek az újakkal az állapot frissítéséért. .task(id:) nélkül manuálisan kellene követni a változásokat .onChange segítségével, és manuálisan kezelni a Task-ot.

Feladatok megszakítása és isCancelled ellenőrzése

Bár a .task automatikusan megszakítja a feladatot a View eltűnésekor, magának az aszinkron műveletnek együttműködően kell ellenőriznie a megszakítást. A Swift együttműködő megszakítási modellt használ — a Task.cancel() nem állítja le erőszakkal a végrehajtást, csak beállítja az isCancelled flag-et. A feladatban lévő kódnak időszakonként ellenőriznie kell ezt a flag-et.

struct LoadingView: View {
    @State var progress: Double = 0
    
    var body: some View {
        ProgressView(value: progress)
            .task {
                for i in 0..<100 {
                    // Megszakítás ellenőrzése
                    try Task.checkCancellation()
                    
                    await Task.sleep(nanoseconds: 50_000_000)
                    progress = Double(i + 1) / 100.0
                }
            }
    }
}

Task.checkCancellation() CancellationError-t dob, ha a feladat meg lett szakítva. Ez a legegyszerűbb ellenőrzési módszer — bármilyen async kontextusban működik. Alternatíva — a Task.isCancelled manuális ellenőrzése költséges műveletek előtt. Az URLSession hálózati kérések automatikusan megszakadnak a feladat megszakításakor, mivel az URLSession a kezdetektől támogatja a Structured Concurrency-t.

Gyakorlati példák a .task használatára

.task számos forgatókönyvhöz alkalmas: az egyszerű JSON betöltéstől a bonyolult, TaskGroup-pal végzett párhuzamos műveletekig. Nézzünk meg három tipikus használati példát.

Betöltés hibakezeléssel

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("Betöltés sikertelen")
            }
        }
        .task {
            defer { isLoading = false }
            do {
                profile = await APIClient().fetchProfile()
            } catch {
                // profil nil marad
            }
        }
    }
}

Párhuzamos betöltés TaskGroup-pal

struct DashboardView: View {
    @State var stats: DashboardStats?
    
    var body: some View {
        Text("Irányítópult")
            .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
            }
    }
}

Gyakori hibák a .task-kal

A leggyakoribb hiba — UI tulajdonságok módosítása a .task-on belül anélkül, hogy átváltanánk a fő szálra. Bár a SwiftUI automatikusan visszaküldi a frissítéseket a fő szálra a @State változásakor async kontextusban, az UIKit elemek közvetlen manipulációja a .task-on belül crash-t okozhat.

• Elfelejtetted a try/catch-t — a .task nem kezeli automatikusan a hibákat. Minden hibát dobó függvényt do/catch-be kell csomagolni, különben az alkalmazás összeomlik.
• Race condition — ha több .task(id:) van elindítva különböző id-kkel és ugyanazt az állapotot frissítik, versenyhelyzet alakulhat ki. Használj külön tulajdonságokat különböző adatforrásokhoz.
• Hosszú szinkron műveletek — a .task nem teszi aszinkronná a szinkron kódot. Ha a .task-on belül nehéz szinkron munka van, csomagold Task.detached-be, vagy helyezd át egy külön async metódusba.
• CancellationError figyelmen kívül hagyása — a Task.checkCancellation() ellenőrzésekor a CancellationError hibát tovább kell propagálni, nem elnyomni. A megszakítás elnyomása memóriaszivárgáshoz vezethet.

// ❌ Hiba: nincs hibakezelés
.task {
    let data = await fetchData() // hibánál összeomlik!
    items = data
}

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