SwiftUI Series 07｜Conversion de la pensée de UIKit à SwiftUI

De nombreux développeurs UIKit passent à SwiftUI pour la première fois. Le plus douloureux n’est pas toujours ce qu’ils ressentent :

• L’API n’est évidemment pas compliquée
• Mais pourquoi est-ce toujours difficile d’écrire ?

La raison en est souvent que le modèle de pensée sous-jacent n’a pas encore été mis en œuvre.

Parce que UIKit demande par défaut :

• Quelle vue dois-je créer maintenant ?
• Quand vais-je le mettre à jour ?
• Comment puis-je le maintenir manuellement cohérent avec les données

SwiftUI revient plutôt à demander :

• Quel est l’état actuel
• À quoi doit ressembler l’interface dans cet état ?
• Comment l’interface doit se réorganiser naturellement lorsque l’état change

Ces deux idées sont que la position du contrôle a changé.

1. La première chose à noter est “Je m’appuie principalement sur mon pilote manuel pour les mises à jour de l’interface”

De nombreuses expériences dans UIKit tournent autour de ceci :

• Quand recharger
• Quand définirNeedsLayout
• Quel rappel pour modifier une certaine sous-vue ?

SwiftUI doit certainement gérer l’état, mais ce qu’il veut faire, c’est :

• Gérer les sources de statut
• Gérer les frontières de l’État
• Comment le statut de gestion est mappé à l’interface utilisateur

Au lieu de continuer à me concentrer sur « comment actualiser l’interface manuellement ? »

Si cette habitude n’est pas modifiée, la situation la plus susceptible de se produire plus tard est :

• SwiftUI semble être écrit dans un style déclaratif
• Mais j’ai toujours en tête le pilote impératif d’UIKit

En fin de compte, le code deviendra un mélange de deux types de pensée, sans tirer parti de SwiftUI ni perdre le sentiment clair de contrôle d’UIKit.

2. La deuxième chose à noter est de traiter View comme un objet stable.

C’est l’habitude que les développeurs ayant une expérience UIKit sont les plus susceptibles d’adopter par défaut.

Dans UIKit, il est naturel de considérer une page ou une cellule comme :

• un objet créé
• Sera mis à jour continuellement à l’avenir

Mais le View de SwiftUI ressemble plus à une description d’état. Il ne s’agit pas « d’un objet que je travaille à modifier depuis longtemps », mais plutôt « de l’expression structurelle de l’interface dans son état actuel ».

Cela signifie que si vous partez toujours de “Cette vue sera toujours là, je continue de la modifier”, il sera facile de :

• Jugement du cycle de vie
• Emplacement de stockage du statut
• Liaison de tâches asynchrones

Des pièges fréquents sur ces questions.

3. La troisième chose à abandonner est la dépendance excessive aux correctifs locaux pour réparer l’interface utilisateur.

Un chemin très courant dans le développement d’UIKit est :

• Éteignez d’abord la vue
• Corrigez tout ce qui ne va pas
• Si un contrôle est un peu déréglé, patchez-le localement.

Cette méthode n’est pas totalement inutilisable dans SwiftUI, mais si vous continuez ainsi, la page deviendra facilement :

• Il y a beaucoup de modificateurs
• Hiérarchie structurelle peu claire
• Une réparation mineure entraîne un autre changement de disposition

Parce que SwiftUI encourage d’abord à exprimer clairement la structure, puis à y attacher des modifications locales. Si la structure elle-même est instable, les correctifs locaux répareront le problème et le briseront en morceaux.

4. La quatrième chose à changer est : penser moins en termes de « contrôles » et plus en termes de « flux d’état »

Dans la pensée UIKit, de nombreuses organisations de pages sont centrées sur le contrôle :

-Que montre cette étiquette ?

• Si ce bouton est désactivé
• Quand cette tableView sera-t-elle rechargée ?

SwiftUI encourage à partir du flux d’état :

• Quel est l’état actuel de la page ?
• Quels fragments d’interface utilisateur doivent être mappés à cet état
• Comment l’état évolue après une action

Ce changement est critique car il affecte directement :

• Comment concevoir ViewModel
• Comment démonter les composants
• Comment déterminer quel statut doit être partagé et lequel ne doit pas être partagé

5. La cinquième chose à changer est la suivante : ne vous précipitez pas pour traduire toute l’expérience UIKit en méthode d’écriture correspondante SwiftUI

Lorsque j’ai découvert ce contenu sur SwiftUI pour la première fois, je posais inconsciemment cette question :

• À quoi cela correspond-il dans UIKit ?
• Quel rappel correspond à ce cycle de vie
• Ce comportement est-il équivalent à reloadData ?

Ce type de cartographie est utile au début, mais il peut poser problème s’il est utilisé à long terme :

• Toujours à la recherche d’un homologue UIKit
• Mais je n’ai pas vraiment accepté que SwiftUI soit une autre façon d’organiser

Le tournant vraiment simple à utiliser est généralement :

J’ai commencé à réfléchir aux pages directement dans la sensibilisation aux problèmes de SwiftUI, plutôt que de d’abord les traduire vers UIKit, puis de prendre des décisions.

6. Une méthode de transition plus pratique : ne recherchez pas un « changement complet du cerveau immédiatement », changez d’abord la façon dont vous posez quelques questions à haute fréquence.

Le plus utile est de commencer par changer la façon dont vous posez ces questions :

Mettez :

• Quand dois-je actualiser cette vue ?

Remplacer par :

• Quels changements d’état devraient entraîner la mise à jour de cette zone

Mettez :

• Quand faut-il modifier ce contrôle ?

Remplacer par :

• À qui appartient cette valeur ?

Mettez :

• Cette page apparaît-elle une ou plusieurs fois ?

Remplacer par :

• À quel état ou cycle de vie cette tâche doit-elle être liée ?

Le changement dans cette façon de demander peut sembler minime, mais il entraînera lentement la réflexion par défaut vers SwiftUI.

7. Conclusion : La chose la plus importante lors du passage d’UIKit à SwiftUI est de repositionner la réflexion sur le contrôle.

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

De UIKit à SwiftUI, ce qui doit vraiment changer, c’est de « Je piloterai manuellement l’interface » à « Je définirai l’état et les limites, et laisserai l’interface être établie en fonction de l’état ».

Une fois que cela commence à se produire, beaucoup de choses qui ressemblaient à l’origine à “Pourquoi SwiftUI est-il si gênant ?” deviendra progressivement naturel.