Étape 1 : comprendre le vrai problème que Riverpod résout
Les problèmes de state Flutter commencent souvent petit : un loading ici, un item sélectionné là, un user passé à travers trois widgets. Puis l’app grandit et l’état devient brumeux. Riverpod donne à chaque état un provider nommé, un lifecycle, des dépendances, du cache et une frontière de test. Le gain n’est pas moins
Étape 2 : modéliser les dépendances comme providers, pas comme globals
Une app Riverpod propre commence en transformant les services en providers. Client API, repository, user courant, feature flags et cache deviennent des dépendances explicites. Chaque feature lit ce dont elle a besoin, et les tests peuvent override sans toucher au code de production.
Étape 3 : sortir le state métier des widgets
Les widgets devraient décrire l’UI, pas décider comment les données sont chargées, mises en cache, retentées ou transformées. Avec Riverpod, un provider async expose l’état de la feature, et le widget rend seulement loading, error ou data. L’UI devient plus lisible et le flux de données plus testable.
Étape 4 : rendre AsyncValue volontairement
`AsyncValue` est une des grandes forces de Riverpod parce qu’il force l’app à admettre que la donnée a plusieurs états : loading, error, refreshing, ready. Au lieu de cacher cette complexité, centralisez-la. Une app polie traite les états de chargement et d’erreur comme une partie du produit.