SwiftUI Series 06 ｜ Fractionnement des composants SwiftUI et maintenabilité du code

Lorsqu’on aborde le sujet du « démontage des composants », la première réaction est :

• Cette vue est trop longue
• Divisez-le en plusieurs sous-vues

C’est certainement un début, mais si le critère de fractionnement est simplement “trop de lignes de code”, il est facile de se retrouver avec un autre type de confusion :

• Il y a effectivement plus de fichiers
• Mais la relation de statut est plus difficile à comprendre
• Les noms de composants deviennent de plus en plus abstraits
• Passer un tas de paramètres entre père et fils

En d’autres termes, la page n’est pas plus claire, elle passe simplement d’un gros fichier à plusieurs fichiers cassés.

La répartition des composants vraiment efficace est donc la suivante :

Rendre plus claires en même temps les limites de la structure, les limites des États et les limites de réutilisation.

1. Distinguez d’abord : est-ce que vous démontez la structure ou la réutilisez-vous ?

Il est fréquent que les deux choses soient confondues.

1. Divisé pour une lisibilité structurelle

Le but est de rendre la hiérarchie actuelle des pages plus claire. Ce type de fractionnement est tout à fait raisonnable même s’il n’est utilisé qu’une seule fois sur une page.

2. Divisé pour une réutilisation sur plusieurs pages

Le but est d’extraire des composants réutilisables. Ce type de division nécessite des frontières plus stables et des interfaces plus restreintes.

Si ces deux types de finalités ne sont pas distinguées, les conséquences les plus courantes sont :

• Evidemment je voulais juste rendre la page plus claire, mais j’ai fini par l’extraire prématurément en tant que “composant universel”
• Ou bien ce modèle a été répété plusieurs fois, mais il est toujours considéré comme une sous-vue partielle

Par conséquent, la première étape du fractionnement des composants consiste à déterminer quel type de problème est résolu.

2. La raison pour laquelle de nombreuses pages deviennent de plus en plus compliquées est que View assume trop de rôles.

Une fois qu’une page prend en charge ces éléments en même temps, il est facile de se développer rapidement :

• structure de mise en page
• État de l’interface utilisateur locale -Cartographie de l’état de l’entreprise
• Formatage des données
• Assemblage d’action interactif

À ce stade, vous constaterez que le code long n’est pas la cause première. Le vrai problème est :

• Quelle logique appartient à View
• Quelle logique devrait être à l’extérieur
• Quelles structures locales méritent une expression indépendante

La véritable valeur du fractionnement des composants est de forcer à nouveau ce jugement de limite.

3. Le plus intéressant à supprimer en premier est généralement “l’élément avec la sémantique la plus complète sur la page actuelle”

Une situation courante est que dès que les composants sont démontés, ils se précipitent pour trouver la pièce la plus polyvalente. Mais dans le développement réel, une approche plus stable consiste souvent à démonter d’abord les éléments sémantiquement complets dans la page actuelle.

Par exemple :

• Zone d’en-tête de données
• Fiche récapitulative de l’article
• Définir la ligne d’article
• Blocs vides

Les avantages de ces structures sont :

• Ils constituent à l’origine une unité indépendante dans la page
• La sémantique structurelle sera plus claire après avoir été supprimée
• Même si vous ne le réutilisez pas pendant un certain temps, vous ne perdrez pas d’argent

C’est beaucoup plus stable que d’essayer de pomper un “conteneur de cellules super universel” dès le début.

4. Une fois les composants supprimés, l’interface devient un véritable problème de conception

L’un des plus grands avantages du fractionnement des composants est qu’il vous oblige à réfléchir aux interfaces.

Vous découvrirez bientôt :

• Ce sous-composant doit-il reprendre le modèle d’origine ou les données d’affichage formatées ?
• Il doit savoir sauter après avoir cliqué, ou n’exposer qu’une seule action
• Doit-il avoir un état local ou être piloté par une couche parent

Si vous ne souhaitez pas comprendre clairement ces problématiques, le composant peut facilement devenir :

• Beaucoup de paramètres
• Sémantique commerciale peu claire
• La couche parent doit tout savoir

Le fractionnement des composants est donc un travail de conception d’interface.

5. Une mauvaise odeur très courante : mélanger le « fractionnement partiel de la structure » et le « fractionnement de la logique métier »

Par exemple, si une fiche de liste est supprimée, elle sera également responsable de :

• Affichage de la mise en page
• Formatage des données
• enterrer le problème
• Jugement commercial après clic

Bien que cette composante soit indépendante, ses responsabilités restent mixtes.

Une approche plus stable est généralement :

• Les composants d’affichage doivent se concentrer autant que possible sur l’affichage
• Maintenir autant que possible les décisions commerciales à des niveaux supérieurs
• Les sous-composants exposent les événements nécessaires sans avaler directement l’ensemble du processus métier

Autrement, plus les composants seront démantelés, plus la logique sera fragmentée, mais la complexité ne diminuera pas.

6. Quand ne faut-il pas se précipiter pour fumer des « composants généraux » ?

C’est à ce stade que de nombreux projets SwiftUI peuvent facilement être surconçus.

Si un modèle n’apparaît actuellement qu’une seule fois sur une page et :

• La structure de l’entreprise n’est pas encore stable
• Les détails de l’interface utilisateur changent encore rapidement
• Je ne suis pas encore sûr des limites

À l’heure actuelle, il est plus approprié de le diviser en sous-vues locales au sein de la page au lieu de le mettre à niveau immédiatement vers un composant général.

Car la « réutilisation prématurée » entraîne souvent une conséquence :

• L’interface des composants devient très large
• Afin d’être compatible avec les scénarios futurs possibles, de nombreuses options sont incluses en premier

Le résultat est qu’il est plus difficile de l’entretenir que de ne pas le démonter.

7. Un jugement pratique : Si cette sous-structure est retirée seule, d’autres peuvent-ils dire de quoi il s’agit ?

C’est une façon très courante pour moi de juger.

Si une certaine sous-structure est supprimée, tout le monde peut naturellement dire :

• Ceci est un en-tête de profil utilisateur
• Ceci est une ligne de paramètres
• Ceci est une fiche de résumé d’article

Ensuite, il convient généralement au démontage.

Si vous le retirez, vous ne pouvez que dire :

• Il s’agit d’un “conteneur combiné”
• Il s’agit d’une “Vue de bloc de contenu”
• Il s’agit d’un “étui à cartes multi-scènes”

Cela signifie très probablement que sa sémantique n’est pas suffisamment stable et que le moment de la scission n’est peut-être pas encore venu.

8. Conclusion : Ce qui est réellement recherché par la division des composants, c’est d’avoir des limites plus claires.

Pour le dire sous une forme plus courte, je dirais :

La norme vraiment efficace pour diviser les composants SwiftUI est qu’après la division, les limites de la structure, les limites des états et les limites de l’interface sont plus claires qu’auparavant.

Seulement de cette manière, les composants deviendront plus légers au fur et à mesure du démontage ; sinon, il y aura facilement plus de fichiers et le système sera plus difficile à lire.