SwiftUI Series 08|Pièges courants de la liste SwiftUI : actualisation, suppression, saut et performances
La vraie difficulté avec List est qu’une fois que l’identité des données, les mises à jour de statut et les comportements d’interaction sont intriqués, il est facile de causer des problèmes ensemble.
List est l’un des contrôles de SwiftUI les plus faciles à « avoir l’air facile à écrire » et également les plus faciles à avoir des ennuis dans les affaires réelles.
Parce que de nombreux exemples simples fonctionnent bien :
- Les données peuvent être affichées dès qu’elles sont ajoutées
- L’actualisation déroulante est également accessible
- Supprimer, sauter et partitionner semblent avoir des capacités prêtes
Mais une fois qu’il commence à apparaître dans le projet :
- Pagination
- Recherche
- Lien de statut après suppression
- Aller aux détails et revenir
- Chargement d’image
Le problème du List sera progressivement exposé.
1. La cause première de nombreux problèmes de List est que « l’identité des données » n’est pas clairement réfléchie.
De nombreux comportements de SwiftUI sont fortement liés à l’identité. Si les données de la liste « se ressemblent » mais que l’identité est instable, elles apparaîtront facilement plus tard :
- Rebondit lors du rafraîchissement
- Animation bizarre lors de la suppression
- La position de défilement est anormale après le retour à la liste
- Le contenu d’une certaine ligne n’est pas actualisé de manière incorrecte
La chose la plus fondamentale et la plus sous-estimée à propos du List est donc :
- L’identité de chaque élément est-elle stable ?
- Cette identité est-elle toujours fiable lors de l’actualisation, de la pagination et de la recherche ?
De nombreuses listes de “bugs métaphysiques”, la cause profonde finale est ici.
2. L’actualisation et la pagination gâchent souvent l’état de la liste.
Parce que l’actualisation et la pagination modifient essentiellement la « collection de listes actuelle », et les modifications de la collection affecteront directement :
- relation de réutilisation des cellules
- position de défilement
- État de chargement actuel
- Basculement entre l’état vide et l’état contenu
Si ces relations ne sont pas clarifiées, il est facile de :
- La liste clignotera lorsque vous la déroulerez pour l’actualiser.
- Revenir en arrière et recalculer la liste entière
- Les anciens résultats écrasent le nouveau contenu
Alors la vraie difficulté avec List est souvent :
- Quels états doivent être conservés lors du rafraîchissement ?
- Quels états doivent être ajoutés lors de la pagination ? -S’il y aura des conflits simultanés entre des demandes du même type
3. Les opérations de suppression ne sont souvent pas aussi simples que « supprimer un élément »
En apparence, la suppression supprime simplement un élément du tableau. Mais dans les vraies listes, la suppression affecte souvent ces éléments en même temps :
- Collection d’exposition actuelle
- Jugement de l’État vide
- état sélectionné
- État de saut
- Statut de synchronisation backend
Si vous « supprimez d’abord, puis parlez », il est facile de :
- La suppression a réussi, mais la page de détails pointe toujours vers l’ancien objet
- Lorsque la suppression échoue, la liste et l’état du serveur sont incohérents
- L’animation est correcte, mais la logique de restauration de la source de données prête à confusion
Cela montre que la vraie difficulté de la suppression est :
- À qui appartient la source de données ?
- La suppression est-elle une mise à jour optimiste ou en attente de confirmation du serveur ?
- Comment fermer le statut de navigation après suppression ?
4. Sauter est facile de s’emmêler avec List et de causer des problèmes.
Il est courant de considérer les listes et les sauts comme des fonctions indépendantes, mais dans les projets réels, ils sont très étroitement liés.
Les questions typiques incluent :
- Supprimez l’élément actuel après avoir cliqué dans les détails et le retour à l’état de la liste est incorrect.
- Une fois la liste actualisée, le chemin initialement sélectionné deviendra invalide.
- Les résultats de la recherche passent aux détails puis reviennent, et l’état de la liste est réinitialisé.
La nature de ces problèmes est généralement :
- Liste de l’état des données
- Statut de l’élément sélectionné
- État du chemin de navigation
ne sont pas traités comme le même ensemble de problèmes.
5. Les problèmes de performances sont particulièrement faciles à exploser dans List
Parce que la liste grossit de nombreux petits problèmes.
Par exemple :
- La hiérarchie des vues des éléments est trop profonde
- Chargement et décodage des images trop tardifs
- La conversion du texte et des données se fait au stade de l’affichage
- La granularité de rafraîchissement est trop grande
Ces coûts peuvent être supportables sur des pages ordinaires, mais dans des scénarios de défilement à haute fréquence comme List, cela peut facilement entraîner des pertes d’images et un scintillement.
Il existe donc de nombreux problèmes de performances du List, et il est particulièrement sensible à l’identité des données, à la plage de rafraîchissement et au timing d’affichage.
6. Une idée plus stable : traitez d’abord List comme une “projection d’état” au lieu de “conteneur de données”
Une situation courante est que lors de la rédaction d’une liste, la valeur par défaut à l’esprit est :
- J’ai un ensemble de données
- Mettre dans la liste
Une idée plus stable dans les projets réels est :
- Quel est l’état actuel de la page ?
- Dans quel lot d’éléments de liste cet ensemble d’états doit-il être projeté ?
- Quels éléments de liste ont des identités stables
- Quelles actions de l’utilisateur modifieront cet ensemble d’états
Une fois que l’on considère List comme une projection d’état plutôt que comme un simple conteneur, de nombreuses questions commencent à devenir claires :
- Donner la priorité à l’identité
- La suppression, l’actualisation et la pagination ne peuvent pas être visualisées séparément
- L’état de saut doit également être considéré ensemble
7. Conclusion : La vraie difficulté de List est que « l’identité, le statut et l’interaction » peuvent facilement s’emmêler.
Pour le dire sous une forme plus courte, je dirais :
Listdans SwiftUI La partie vraiment difficile est qu’une fois que les interactions de l’identité des données, de l’état de la page et de la suppression/actualisation/saut sont étroitement liées, si une frontière n’est pas établie, les problèmes seront exposés ensemble.
Par conséquent, si vous souhaitez utiliser List de manière stable, la clé est d’abord de :
- identité de l’article
- Statut de la liste
- Flux de statut après interaction
Redressez ces trois choses.
What to read next
Want more posts about SwiftUI?
Posts in the same category are usually the best next step for reading more on this topic.
View same categoryWant to keep following #iOS?
Tags are useful for related tools, specific problems, and similar troubleshooting notes.
View same tagWant to explore another direction?
If you are not sure what to read next, return to the homepage and start from categories, topics, or latest updates.
Back home