some View — qu’est-ce que c’est, type opaque dans SwiftUI

Qu’est-ce que some View dans SwiftUI ?

some View est une syntaxe de type opaque introduite dans Swift 5.1. Elle est utilisée comme type de retour de la propriété body du protocole View. La notation some View signifie : « la fonction ou propriété retourne un type concret qui se conforme au protocole View, mais le code appelant ne sait pas et ne doit pas savoir lequel ».

Le concept de type opaque est le revers de la programmation générique (generics). Si les generics permettent au code appelant de déterminer le type, le type opaque permet à l’implémentation de déterminer le type, en le cachant à l’appelant. Cela donne au développeur la liberté de modifier l’implémentation interne sans changer le contrat.

Selon Swift Evolution SE-0244, les types opaques ont été ajoutés pour supporter SwiftUI et le motif des protocoles avec types associés (PAT), qui ne peuvent pas être utilisés comme type de retour sans cette construction.

Pourquoi some View est nécessaire

Sans some View, la signature body serait impossible : le protocole View a un type associé Body qui se conforme à View. Si body retournait simplement View (comme protocole), Swift ne pourrait pas travailler avec des protocoles ayant des exigences Self en position de retour. some View résout ce problème en fournissant un type concret mais caché.

Type opaque : mécanisme de fonctionnement

Le type opaque est un type spécial qui se comporte comme concret pour le compilateur mais comme abstrait pour le développeur. Lorsque le compilateur voit some View, il analyse l’implémentation et détermine le type de retour exact. Ce type est fixé et utilisé pour la génération de code sans dispatch dynamique.

struct SimpleView: View {
    var body: some View {
        Text("Bonjour")
    }
}
// Le compilateur voit : body -> Text, not some View

Principe de fonctionnement : Le compilateur Swift déduit le type concret de l’implémentation. Dans l’exemple ci-dessus, le corps contient uniquement Text, donc le compilateur sait que body retourne exactement Text, même si la signature est écrite comme some View. Cela offre deux optimisations : appel direct sans table de méthodes virtuelles et possibilité d’inlining.

Si l’implémentation de body change (par exemple, au lieu de Text, un VStack de Text et Button est retourné), le compilateur redéfinit le type concret. Mais pour le code appelant (SwiftUI), la signature reste la même — some View. C’est le revers des generics : le code appelant ne dépend pas des changements d’implémentation.

Fixation du type et stabilité

Une des règles clés des types opaques : une fonction ou propriété retournant some View doit toujours retourner le même type concret. On ne peut pas retourner Text dans une branche if et Image dans une autre. Cette limitation est vérifiée par le compilateur et sert de garantie pour le code appelant.

struct BadView: View {
    var flag: Bool
    var body: some View {
        if flag {
            Text("Vrai")   // Erreur : Text vs VStack
        } else {
            VStack {
                Text("Faux")
                Image(systemName: "xmark")
            }
        }
    }
}

Pour résoudre ce problème, on utilise @ViewBuilder, qui enveloppe différentes branches dans un conteneur conditionnel ConditionalContent. L’annotation @ViewBuilder sur body est une pratique standard dans SwiftUI, bien qu’elle puisse être implicite si body ne contient qu’une seule expression.

some View vs AnyView : comparaison

AnyView est un type qui efface l’implémentation concrète de View (type erasure). Il enveloppe n’importe quel View dans un unique emballage, permettant de stocker des Views de différents types dans le même conteneur. Contrairement à some View, AnyView fonctionne à l’exécution et ajoute une surcharge d’empaquetage et de dépaquetage.

Quand utiliser AnyView : uniquement dans les situations où some View est impossible en raison de la nécessité d’un changement dynamique de type à l’exécution. Par exemple, lors du retour d’un View depuis un dictionnaire ou dans une structure récursive où le type concret doit changer à chaque niveau. AnyView doit être minimisé, car chaque empaquetage désactive les optimisations de SwiftUI.

Idée reçue courante : AnyView ne résout pas le problème des différents types dans body — c’est @ViewBuilder qui le résout. AnyView efface le type mais n’aide pas le compilateur à déduire un type unique. Utilisez @ViewBuilder pour la logique conditionnelle et AnyView uniquement pour le dispatch dynamique.

some View et @ViewBuilder : travail conjoint

@ViewBuilder est un result builder conçu spécifiquement pour travailler avec some View. Il permet d’utiliser une logique conditionnelle (if/else, switch) et des expressions multiples dans le body tout en maintenant un type de retour unique. ViewBuilder enveloppe automatiquement les expressions multiples dans TupleView et les branches conditionnelles dans ConditionalContent.

struct ProfileView: View {
    let user: User?

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

Comment ça fonctionne : @ViewBuilder analyse le bloc de code et génère l’appel approprié buildBlock, buildOptional ou buildEither. Pour la logique conditionnelle, ConditionalContent est créé — un type commun qui cache les types concrets à l’intérieur des branches mais est lui-même un type unique pour le compilateur. Cela résout le problème des différents types concrets.

Sans @ViewBuilder, une propriété body contenant des expressions multiples ou une logique conditionnelle provoquerait une erreur de compilation. C’est pourquoi SwiftUI applique @ViewBuilder à body implicitement, et pour les propriétés et fonctions personnalisées, il doit être ajouté explicitement.

Imbrication de @ViewBuilder

@ViewBuilder peut être imbriqué : un ViewBuilder à l’intérieur d’un autre. Cela permet de créer des hiérarchies complexes avec des conditions à différents niveaux. Cependant, une imbrication profonde complique la lisibilité, il est donc recommandé d’extraire les conditions imbriquées dans des composants View séparés.

Exemples pratiques de some View

Exemple 1 : retourner un View personnalisé depuis une propriété calculée. Une propriété peut retourner some View, cachant la composition interne. Cela permet de réorganiser le code sans modifier l’interface publique.

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)
    }
}

Exemple 2 : passer un View comme closure via @ViewBuilder. Ce motif est utilisé dans les conteneurs standard de SwiftUI (VStack, HStack, List) et peut être implémenté dans des composants personnalisés.

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

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

Exemple 3 : une fonction d’usine qui retourne some View. Permet de créer des Views en fonction de paramètres sans révéler l’implémentation. C’est particulièrement utile pour les bibliothèques et les composants réutilisables.

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()
    }
}