Gestion d'état

Le sujet a une mauvaise réputation, entretenue par la quantité de solutions concurrentes et par les débats qu'elles suscitent. Il faut la dissiper d'emblée : le problème réel n'est pas de choisir entre trois bibliothèques, c'est de répondre à une question simple pour chaque donnée de votre application. Qui en a besoin ?

Une case à cocher n'intéresse que la ligne qui la contient : setState suffit, et n'importe quoi d'autre serait une complication gratuite. Le panier d'achat, lui, est lu par la liste des produits, par le badge de la barre supérieure, par l'écran de commande et par l'écran de paiement — quatre endroits qui ne partagent aucun ancêtre commun proche. Faire descendre le panier de constructeur en constructeur à travers six niveaux de widgets fonctionne, mais produit un code où le moindre changement touche dix fichiers. Ce phénomène a un nom, le forage de propriétés, et c'est lui, pas setState, qui motive l'existence de Provider.

Cette leçon suit exactement cette progression : setState et ce qu'il fait bien, le mur qu'il rencontre, InheritedWidget qui est le mécanisme du framework pour le franchir, puis Provider qui l'emballe de manière utilisable au quotidien. À la fin, vous aurez un critère de décision, pas une préférence.