SwiftUI Series 02｜Introduction au système de mise en page SwiftUI : VStack, HStack, ZStack, Spacer et frame

Lorsque j’ai appris ce contenu pour la première fois, il était plus facile de tomber dans un état lors de la conception de la mise en page SwiftUI :

• VStack je peux
• HStack Moi aussi
• Spacer semble comprendre
• frame écrit aussi souvent

Mais à mesure que la page devient plus complexe, ces problèmes familiers commencent à apparaître :

• Cette vue n’est pas complète
• Ajout de frame mais toujours pas aligné
• Spacer Dès qu’il est placé, il évince d’autres choses.
• Après plusieurs niveaux d’imbrication, la page “ne peut pas dire ce qui ne va pas, mais ça n’a pas l’air bien”

Cela montre que souvent, nous ne comprenons pas vraiment ce que fait la mise en page SwiftUI.

1. La chose la plus importante à propos de la mise en page SwiftUI est le processus de négociation de la taille

Si vous comprenez uniquement la mise en page comme « quelle pile utiliser pour placer les éléments », vous serez bientôt bloqué. Parce que le véritable cœur de la mise en page SwiftUI est un processus de négociation de taille, qui peut être grossièrement compris comme :

1. L’aperçu donne un espace disponible ou une taille proposée
2. La sous-vue décide de sa taille en fonction de cette proposition
3. Le conteneur parent organise ensuite la mise en page en fonction de la taille renvoyée par la sous-vue.

En d’autres termes, l’aménagement est une négociation constante entre père et fils.

Une fois cette prémisse comprise, de nombreuses questions apparemment métaphysiques deviennent claires :

• Certains frame sont juste recouverts d’une coque
• Text et Spacer se comportent très différemment lorsqu’ils sont assemblés
• Certains problèmes d’alignement sont essentiellement compensés lors de la phase de proposition de taille.

2. VStack, HStack, ZStack La vraie différence est « qui dirige quelle logique de placement »

En surface :

• VStack Disposé verticalement
• HStack disposé horizontalement
• Rangées empilées ZStack

C’est certainement vrai, mais si vous vous en souvenez seulement, vous serez toujours confus lorsque vous rencontrerez des mises en page complexes.

Une compréhension plus pratique est la suivante :

• VStack organise principalement les sous-éléments verticalement
• HStack organise principalement les sous-éléments horizontalement
• ZStack empile principalement plusieurs éléments dans la même zone

Le point clé est de penser clairement :

• Quel est l’axe central de la page actuelle ?
• Quelle couche est responsable de la mise en page principale -Quelle couche est uniquement un alignement et une décoration locaux

De nombreuses mises en page sont rédigées de manière désordonnée et les niveaux primaire et secondaire ne sont pas clairement distingués.

3. La valeur de Spacer est “manger l’espace restant”

Lorsque vous utilisez Spacer pour la première fois, vous comprendrez intuitivement cela comme « l’ajout d’une boîte vide ».

Cela peut conduire à de nombreux abus.

Plus précisément, ce que fait Spacer est :

Consommez autant d’espace restant que possible dans la direction de l’axe principal du conteneur actuel.

Par exemple, dans HStack, il consomme l’espace horizontal ; dans VStack, il occupe l’espace vertical.

Une fois compris ainsi, il devient plus facile de juger :

-Est-il nécessaire d’avoir un espacement fixe ou d’attribuer l’espace restant ?

• Faut-il utiliser padding ou Spacer ici ?
• Spacer S’il est placé dans la mauvaise position, le centre de gravité de l’ensemble du réseau sera déplacé.

De nombreuses pages « semblent un peu moins bonnes » car Spacer est utilisé là où des contraintes fixes doivent être utilisées. En conséquence, la disposition est discrètement modifiée par la logique d’allocation d’espace restante.

4. frame est très facilement mal compris : il ne s’agit pas nécessairement de “modifier la taille du contenu”, dans de nombreux cas, il s’agit simplement d’envelopper une couche de zones de mise en page

C’est l’un des points les plus faciles à bloquer pour les débutants de SwiftUI.

Une situation courante consiste à écrire :

Text("Hello")
  .frame(maxWidth: .infinity)

Je pensais que j’étirais le Text. Pour être plus précis, dans de nombreux cas, une zone de mise en page plus grande est fournie à l’extérieur du Text, plutôt que de modifier la taille du contenu interne du Text lui-même.

Cela explique de nombreuses confusions courantes :

• Il semble plus large, mais le texte n’est toujours pas aligné là où je souhaite qu’il soit.
• Utilisez-le simplement avec alignment
• Le même frame a des effets différents sur différentes vues

Par conséquent, la clé de frame n’est pas de « modifier la taille », mais de « quelles limites de mise en page sont ajoutées à la vue ».

5. La véritable cause de nombreux problèmes de mise en page est que la « couche de mise en page principale » et la « couche de modification locale » sont mélangées

Prenons un anti-modèle très courant :

• Une couche externe VStack
• Il y a plusieurs couches à l’intérieur du HStack
• Ajoutez frame à chaque couche
• Mélangez encore un peu de Spacer
• Enfin, comptez sur padding pour le réparer jusqu’à ce que vous puissiez le voir.

Ce type de méthode d’écriture peut certes produire des résultats à court terme, mais une fois que vous modifiez la longueur de la copie, la largeur de l’écran ou la police dynamique, la mise en page commence à dériver.

La racine du problème est souvent :

• Quelle couche est responsable de la structure principale
• Quelle couche est responsable de l’alignement local -Quel calque est juste une modification visuelle ?

Il n’y a pas de superposition.

Une fois que la mise en page perdra son sens de la hiérarchie, elle deviendra « s’appuyant sur un tas de modificateurs pour retirer temporairement la position » au lieu de s’appuyer sur la structure pour être établie naturellement.

6. Une façon plus pratique de penser l’aménagement : déterminer d’abord l’axe principal, puis déterminer l’espace restant, puis déterminer l’alignement local

Si je veux créer une page légèrement plus complexe aujourd’hui, je pense généralement dans cet ordre :

1. Cette zone est-elle dominée horizontalement ou verticalement ?
2. À qui doit laisser l’espace restant ?
3. Quels endroits nécessitent un espacement fixe et quels endroits nécessitent un espace flexible.
4. Quels domaines ne sont alignés que localement et ne devraient pas affecter à leur tour la structure globale.

Cette ordonnance peut réduire considérablement la situation de « plus de réparations et plus de chaos ». Parce que cela vous oblige à décider d’abord de la structure, puis à décider de la modification, au lieu de simplement compter sur un modificateur pour accumuler les résultats.

7. De nombreuses pages SwiftUI « ont toujours l’air un peu moins bien »

De nombreux problèmes de page sont en réalité causés par une expression de structure insuffisamment claire.

Les manifestations courantes comprennent :

• La relation entre les blocs d’informations n’est pas assez stable
• Tant que le texte est long, il éclipsera d’autres choses.
• La même carte a des proportions étranges sur différents écrans

Ces questions sont souvent :

• La logique d’allocation de l’espace n’est pas claire
• L’axe principal d’implantation et les modifications locales sont mixtes
• Le lieu fixe n’est pas fixe
• La flexibilité a été à nouveau notée

Par conséquent, pour véritablement apprendre l’aménagement, il faut apprendre à juger comment l’espace doit être alloué.

8. Conclusion : Ce que vous devez vraiment apprendre lorsque vous débutez avec la mise en page SwiftUI, c’est la négociation d’espace plutôt que les noms de contrôle.

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

Ce que vous devez vraiment maîtriser dans la mise en page SwiftUI, c’est comment la vue parent propose la taille, comment la sous-vue répond à la taille et comment le conteneur est placé en fonction de ces résultats.

Une fois cette relation fondamentale établie, de nombreux problèmes de mise en page passeront du « métaphysique » au « raisonnable ».