dimillian/swiftui-view-refactor

Que fait swiftui-view-refactor ?

Refactorisez et révisez des fichiers de vues SwiftUI avec des bonnes pratiques strictes pour des sous-vues dédiées de petite taille, un flux de données MV plutôt que MVVM, des arbres de vues stables, une injection de dépendances explicite et une utilisation correcte d'Observation. À utiliser lors du nettoyage d'une vue SwiftUI, pour diviser de longs corps, supprimer des actions ou effets de bord en ligne, réduire les helpers some View calculés, ou standardiser les motifs @Observable et d'initialisation de view model.

Principes

• Sous-vues dédiées : Extrayez les parties de votre vue en sous-vues nommées et de petite taille. Évitez les vues uniques gigantesques.
• Flux MV plutôt que MVVM : Préférez le couple Model-View (MV) pour la logique et les données, en évitant la complexité inutile du MVVM.
• Arbres de vues stables : Assurez-vous que l'arbre de vues reste stable entre les rendus. Évitez les changements conditionnels ou dynamiques qui cassent les transitions et animations.
• Injection de dépendances explicite : Passez les dépendances (services, configurations) explicitement comme paramètres, évitez les variables globales ou les singletons non nécessaires.
• Observation correcte : Utilisez @Observable pour les modèles et suivez les règles du framework Observation (propriétés observables, pas de mutations dans les vues).

Étapes de refactorisation

1. Identifier le problème : Sur quels aspects de la vue souhaitez-vous travailler ? Longueur excessive, modifications d'état en ligne, helpers some View surutilisés, ou initialisation non standard.
2. Découper en sections : Divisez la vue en parties logiques (titre, contenu, boutons, etc.) et extrayez-les en sous-vues si nécessaire.
3. Réduire les helpers some View : Transformez les helpers some View en vues séparées, nommées et réutilisables.
4. Supprimer les actions et effets de bord en ligne : Déplacez la logique dans le modèle ou dans des fonctions dédiées du view model (si vous utilisez cette architecture). Privilégiez le passage de fermetures ou de méthodes.
5. Standardiser l'initialisation : Si vous utilisez un view model, passez-le en paramètre (@StateObject ou @ObservedObject) et évitez l'initialisation à l'intérieur du body.
6. Vérifier les @Observable : Assurez-vous que tous les états observables sont marqués avec @Observable ou @Published selon le besoin, et que les vues ne mutent pas directement les observables.

Exemples

Avant refactorisation

struct ContentView: View {
    @State private var count = 0
    @State private var showDetail = false
    var body: some View {
        VStack {
            HStack {
                Text("Titre")
                    .font(.title)
                Spacer()
                Button("Action") {
                    count += 1
                    showDetail.toggle()
                }
            }
            .padding()
            if showDetail {
                VStack {
                    Text("Détail")
                        .font(.body)
                    Text("Compteur : \(count)")
                }
            }
        }
    }
}

Après refactorisation

struct ContentView: View {
    @State private var count = 0
    @State private var showDetail = false

    var body: some View {
        VStack {
            HeaderView(showDetail: $showDetail, count: $count)
            if showDetail {
                DetailView(count: count)
            }
        }
    }
}

struct HeaderView: View {
    @Binding var showDetail: Bool
    @Binding var count: Int

    var body: some View {
        HStack {
            Text("Titre")
                .font(.title)
            Spacer()
            Button("Action") {
                count += 1
                showDetail.toggle()
            }
        }
        .padding()
    }
}

struct DetailView: View {
    let count: Int

    var body: some View {
        VStack {
            Text("Détail")
                .font(.body)
            Text("Compteur : \(count)")
        }
    }
}

Vérifications à faire

• Chaque sous-vue a-t-elle un nom clair et descriptif ?
• Les vues ne contiennent-elles pas d'actions ou d'effets de bord dans le body (sauf pour les boutons ou gestes) ?
• Les helpers some View sont-ils tous extraits en vues séparées ?
• L'injection de dépendances est-elle explicite (paramètres passés aux vues) ?
• @Observable ou @Published sont-ils utilisés correctement sans mutations dans les vues ?
• L'arbre de vues est-il stable (pas de changements conditionnels qui cassent les transitions) ?

Références

• Documentation SwiftUI d'Apple
• Guide sur le framework Observation
• Principes MV vs MVVM