some View — wat is het, het ondoorzichtige type in SwiftUI

Wat is some View in SwiftUI?

some View — is de syntax van het ondoorzichtige type (opaque type), geïntroduceerd in Swift 5.1. Het wordt gebruikt als het returntype van de body-eigenschap van het View-protocol. De notatie some View betekent: „de functie of eigenschap retourneert een concreet type dat voldoet aan het View-protocol, maar de aanroepende code weet niet en hoeft niet te weten welk type precies”.

Het concept van het ondoorzichtige type is de keerzijde van generisch programmeren (generics). Terwijl generics de aanroepende code in staat stellen het type te bepalen, stelt opaque type de implementatie in staat het type te bepalen, het verbergend voor de aanroeper. Dit geeft de ontwikkelaar de vrijheid om de interne implementatie te wijzigen zonder het contract te veranderen.

Volgens Swift Evolution SE-0244 zijn opaque types toegevoegd ter ondersteuning van SwiftUI en het patroon van protocollen met geassocieerde typen (PAT), die zonder deze constructie niet als returntype kunnen worden gebruikt.

Waarom is some View nodig

Zonder some View zou de body-handtekening onmogelijk zijn: het View-protocol heeft een geassocieerd type Body dat voldoet aan View. Als body gewoon View (als protocol) zou retourneren, zou Swift niet kunnen werken met protocollen met Self requirements in de retourpositie. some View lost dit probleem op door een concreet maar verborgen type te bieden.

Ondoorzichtig type: werkingsmechanisme

Ondoorzichtig type (opaque type) — is een speciaal soort type dat zich gedraagt als concreet voor de compiler, maar als abstract voor de ontwikkelaar. Wanneer de compiler some View ziet, analyseert hij de implementatie en bepaalt het exacte returntype. Dit type wordt vastgesteld en gebruikt voor codegeneratie zonder dynamische dispatch.

struct SimpleView: View {
    var body: some View {
        Text("Hallo")
    }
}
// Compiler ziet: body -> Text, niet some View

Werkingsprincipe: De Swift-compiler leidt het concrete type af uit de implementatie. In het bovenstaande voorbeeld bevat de body alleen Text, dus de compiler weet dat body precies Text retourneert, hoewel de handtekening is geschreven als some View. Dit biedt twee optimalisaties: directe aanroep zonder virtuele methodetabel en de mogelijkheid van inlining.

Als de body-implementatie verandert (bijvoorbeeld in plaats van Text wordt een VStack met Text en Button geretourneerd), bepaalt de compiler het concrete type opnieuw. Maar voor de aanroepende code (SwiftUI) blijft de handtekening hetzelfde — some View. Dit is de keerzijde van generics: de aanroepende code is niet afhankelijk van implementatiewijzigingen.

Typevaststelling en stabiliteit

Een van de belangrijkste regels van opaque type: een functie of eigenschap die some View retourneert, moet altijd hetzelfde concrete type retourneren. Je kunt niet in de ene if-tak Text retourneren en in de andere Image. Deze beperking wordt door de compiler gecontroleerd en is een garantie voor de aanroepende code.

struct BadView: View {
    var flag: Bool
    var body: some View {
        if flag {
            Text("Waar")   // Fout: Text vs VStack
        } else {
            VStack {
                Text("Onwaar")
                Image(systemName: "xmark")
            }
        }
    }
}

Om dit probleem op te lossen wordt @ViewBuilder gebruikt, die verschillende takken in een conditionele container ConditionalContent wikkelt. De @ViewBuilder-annotatie boven body — standaardpraktijk in SwiftUI, hoewel deze impliciet kan zijn als body slechts één expressie bevat.

some View vs AnyView: vergelijking

AnyView — is een type dat de concrete View-implementatie wist (type erasure). Het wikkelt elke View in een uniforme wrapper, waardoor Views van verschillende typen in één container kunnen worden opgeslagen. In tegenstelling tot some View werkt AnyView tijdens runtime en voegt overhead toe voor in- en uitpakken.

Wanneer AnyView gebruiken: alleen in situaties waar some View niet mogelijk is vanwege de vereiste van dynamische typewijziging tijdens runtime. Bijvoorbeeld bij het retourneren van een View uit een woordenboek of bij een recursieve structuur waar het concrete type op elk niveau moet veranderen. AnyView moet worden geminimaliseerd omdat elke verpakking SwiftUI-optimalisaties uitschakelt.

Verkeerde opvatting: AnyView lost het probleem van verschillende typen in body niet op — dit probleem lost @ViewBuilder op. AnyView wist het type, maar helpt de compiler niet om een uniform type af te leiden. Gebruik @ViewBuilder voor conditionele logica en AnyView alleen voor dynamische dispatch.

some View en @ViewBuilder: samenwerking

@ViewBuilder — is een result builder, speciaal gemaakt voor het werken met some View. Het maakt het gebruik van conditionele logica (if/else, switch) en meerdere expressies in de body mogelijk, terwijl een uniform returntype behouden blijft. ViewBuilder wikkelt automatisch meerdere expressies in TupleView en conditionele takken in ConditionalContent.

struct ProfileView: View {
    let user: User?

    @ViewBuilder
    var body: some View {
        if let user {
            UserCard(user: user)
            Text("Online")
                .font(.caption)
        } else {
            ProgressView("Loading...")
        }
    }
}

Hoe het werkt: @ViewBuilder analyseert het codeblok en genereert de overeenkomstige aanroep van buildBlock, buildOptional of buildEither. Voor conditionele logica wordt ConditionalContent gemaakt — een gemeenschappelijk type dat de concrete typen in de takken verbergt, maar zelf een uniform type is voor de compiler. Dit lost het probleem van verschillende concrete typen op.

Zonder @ViewBuilder zou de body-eigenschap met meerdere expressies of conditionele logica een compilatiefout veroorzaken. Daarom past SwiftUI @ViewBuilder impliciet toe op body, en voor aangepaste eigenschappen en functies moet het expliciet worden toegevoegd.

Nesting van @ViewBuilder

@ViewBuilder kan worden genest: de ene ViewBuilder binnen de andere. Dit maakt het mogelijk om complexe hiërarchieën te creëren met voorwaarden op verschillende niveaus. Diepe nesting bemoeilijkt echter de leesbaarheid, dus wordt aanbevolen om geneste voorwaarden naar aparte View-componenten te verplaatsen.

Praktische voorbeelden van some View

Voorbeeld 1: het retourneren van een aangepaste View uit een berekende eigenschap. De eigenschap kan some View retourneren, waarbij de interne compositie verborgen blijft. Dit maakt het mogelijk om code te reorganiseren zonder de openbare interface te wijzigen.

struct ArticleView: View {
    var body: some View {
        CardView {
            HeaderView()
            ContentView()
            FooterView()
        }
    }
}

struct CardView<Content: View>: View {
    let content: Content

    var body: some View {
        content
            .padding(16)
            .background(.white)
            .cornerRadius(12)
            .shadow(radius: 4)
    }
}

Voorbeeld 2: het doorgeven van een View als een closure via @ViewBuilder. Dit patroon wordt gebruikt in standaard SwiftUI-containers (VStack, HStack, List) en kan worden geïmplementeerd in aangepaste componenten.

struct CustomContainer<Content: View>: View {
    @ViewBuilder let content: () -> Content

    var body: some View {
        VStack(alignment: .leading) {
            content()
        }
        .padding(20)
    }
}

Voorbeeld 3: een fabrieksfunctie die some View retourneert. Maakt het mogelijk om Views te maken op basis van parameters zonder de implementatie prijs te geven. Dit is vooral handig voor bibliotheken en herbruikbare componenten.

func makeIcon(for status: Status) -> some View {
    switch status {
    case .success:
        Image(systemName: "checkmark.circle.fill")
            .foregroundColor(.green)
    case .error:
        Image(systemName: "xmark.circle.fill")
            .foregroundColor(.red)
    case .pending:
        ProgressView()
    }
}