SwiftUI Series 05｜Utilisation correcte de NavigationStack et saut de page

Lorsque vous utiliserez NavigationStack pour la première fois, vous penserez qu’il s’agit de la version SwiftUI du conteneur de navigation :

• Cliquez
• pousser une page
• C’est à peu près ça

Mais dans les projets réels, la partie la plus problématique de la navigation est toujours :

• La page va sauter
• Si le statut du saut et le statut de l’entreprise sont cohérents
• Si le chemin peut toujours rester correct lors d’un lien profond, d’un retour et d’une nouvelle saisie sur la page

En d’autres termes, ce que le NavigationStack doit réellement gérer n’est pas seulement le changement d’interface, mais l’état de navigation lui-même.

1. Les problèmes de navigation de nombreux projets dans le passé provenaient essentiellement d’“actions de saut dispersées partout”

À l’ère UIKit, une manière d’écrire très courante est :

• Appuyez directement sur un bouton
• Présenter directement dans un rappel
• Lorsqu’un ViewModel rappelle, il passe par le délégué

Bien sûr, cela fonctionnera à court terme, mais le problème est que les logiques de navigation vont devenir de plus en plus dispersées. Difficile de répondre :

• Pourquoi es-tu sur cette page ?
• Dans quel état devez-vous retourner après votre retour ?
• Une fois qu’une certaine activité est terminée, elle passera à deux niveaux.

Le NavigationStack de SwiftUI offre une meilleure chance : Changez le « chemin de navigation actuel » d’une action implicite à un état explicite.

2. La chose la plus importante à propos du NavigationStack est le chemin

Quand j’ai appris ce contenu NavigationStack pour la première fois, j’ai juste regardé :

• NavigationLink
• navigationDestination

Bien sûr, vous devez les connaître, mais ce qu’il faut d’abord comprendre est :

La navigation peut être exprimée sous forme de chemin d’état dans SwiftUI.

Cela ne signifie plus simplement « sauter sur clic », mais maintenir :

• Quelles pages se trouvent dans le chemin actuel ?
• Quel statut d’entreprise correspond à quelle destination
• Comment le chemin doit-il changer après une certaine opération ?

Une fois vue sous cet angle, la navigation cesse d’être un simple événement d’interface utilisateur et commence à faire partie du flux d’état.

3. De nombreuses navigations sont gâchées car le statut commercial et le statut de routage ne sont pas alignés.

Pour donner un exemple très courant :

• L’utilisateur sélectionne un article
• La page de détails de l’article devrait apparaître
• Comment quitter la page de détails après avoir supprimé un article ?

Si vous comprenez simplement la navigation comme « cliquez pour entrer », alors de nombreuses questions ultérieures commenceront à prêter à confusion :

• Comment restaurer le chemin lorsqu’un lien profond arrive
• Comment ajuster le chemin après une panne de données
• Dans quel état la liste doit rester une fois renvoyée

Ce qui est vraiment difficile avec la navigation, c’est qu’elle ne doit pas exister indépendamment de l’état des affaires.

Une idée plus stable est :

• Le chemin de navigation et le statut de l’entreprise sont mutuellement interprétables
• La raison pour laquelle vous êtes actuellement sur cette page peut être clairement expliquée à partir du statut.

4. NavigationLink est très pratique, mais une fois le projet complexe, on ne peut pas compter sur lui pour exprimer toute la navigation

Le NavigationLink est particulièrement adapté aux sauts directs, partiels et simples, tels que :

• Cliquez sur la liste pour plus de détails
• Définir les paramètres de flux de page

Mais si le projet est complexe, si toute la navigation repose sur des NavigationLink épars, vous rencontrerez bientôt :

• Les chemins sont difficiles à gérer uniformément
• Les liens profonds sont difficiles d’accès
• Certains sauts de processus ne se font plus simplement par clic.
• Le chemin de retour est déconnecté du statut de l’entreprise

C’est pourquoi il est plus adapté pour prendre en charge les entrées locales et n’est pas adapté pour porter seul la stratégie de navigation de l’ensemble de l’application.

5. Une idée plus pratique : concevoir la « destination de la page » comme une valeur explicable par le business

L’une des causes profondes de nombreux accidents de navigation liés aux projets est :

• Les sauts sont simplement écrits sous la forme d’un ensemble d’actions de l’interface utilisateur
• Aucun modèle de destination raisonnable n’est formé

Une méthode plus stable consiste généralement à laisser le chemin porter « la destination vers laquelle l’entreprise actuelle souhaite se rendre ».

Par exemple :

• articleDetail (id : chaîne)
• profil utilisateur (identifiant : chaîne)
• paramètres

De cette façon, la navigation ressemble davantage à des états qu’à un ensemble disjoint d’actions. Ses avantages sont :

• Les chemins peuvent être reconstruits
• Les liens profonds sont plus naturels
• Les tests et le débogage sont également plus faciles à décrire

6. La mauvaise odeur la plus courante dans les projets réels : View, ViewModel et les actions de routage sont étroitement liées les unes aux autres

Une grande partie du code de navigation SwiftUI finit par ressembler à ceci :

• Écrire une partie de NavigationLink dans View
• Le ViewModel a secrètement décidé de sauter à nouveau
• Un certain rappel de service déclenche un changement d’état de navigation

Au final, personne ne peut le dire clairement :

• Qui est le véritable propriétaire de la navigation
• Quel état détermine le chemin actuel
• Une certaine action de retour est-elle un comportement d’utilisateur ou un comportement d’entreprise ?

Une fois que la navigation entre dans cet état, le coût de l’ajout d’un lien profond ou d’un chemin de récupération augmentera considérablement.

7. Un jugement pratique : la page actuelle est-elle “parce que j’ai cliqué dessus” ou “parce que le statut détermine qu’elle devrait être ici”

C’est une question que je me pose souvent.

Si une page apparaît, elle ne peut être interprétée que comme :

• Parce que je viens de cliquer sur un bouton

Cela signifie généralement que la navigation est encore trop axée sur l’action.

Une explication plus idéale devrait être :

• parce que l’état actuel du chemin le contient
• parce que le contexte économique actuel impose de l’afficher

Cette différence est importante. La première s’apparente davantage à une action temporaire, la seconde s’apparente davantage à un état de navigation maintenable.

8. Conclusion : Ce que NavigationStack permet réellement de gérer, ce ne sont pas seulement les sauts, mais aussi l’état du chemin.

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

NavigationStack La chose vraiment importante est qu’elle permet de fermer plus naturellement la navigation des “actions de clic dispersées” à “l’état du chemin gérable”.

Par conséquent, la bonne façon d’ouvrir le saut de page n’est pas seulement d’écrire NavigationLink, mais de permettre à l’état de navigation et à l’état de l’entreprise de s’expliquer mutuellement. Seulement de cette façon, la navigation ne deviendra pas de plus en plus confuse à mesure que le projet deviendra plus complexe.