La gestion d etat est l endroit ou les projets Flutter restent sains ou pourrissent. Le framework fournit setState, qui convient pour un seul widget, mais des que l etat doit etre partage entre ecrans il faut mieux. J ai livre des applications avec Provider, Riverpod et Bloc, et chacun gagne sa place dans des situations differentes. Voici comment je choisis.
Pourquoi setState ne suffit plus
setState reconstruit le widget dans lequel il vit. Cela marche jusqu a ce que deux ecrans aient besoin des memes donnees, ou qu un enfant profond ait besoin d une valeur tenue pres de la racine. Vous finissez par passer des callbacks et des valeurs vers le bas a travers les constructeurs, couche apres couche, et le terme pour cette misere est le prop drilling. Chaque bibliotheque d etat existe pour resoudre ce meme probleme: amener les donnees la ou elles sont necessaires sans les enfiler a travers tout le reste.
Provider, le depart en douceur
Provider est longtemps la recommandation officielle et reste un choix par defaut raisonnable. Il s appuie sur les inherited widgets et offre une facon propre d exposer une valeur a l arbre en dessous. Un ChangeNotifier tient votre etat et appelle notifyListeners quand quelque chose change, et les widgets qui ecoutent se reconstruisent. C est simple a raisonner et facile a enseigner a un nouveau membre.
import 'package:flutter/material.dart';
class CartModel extends ChangeNotifier {
final List<String> _items = [];
List<String> get items => _items;
void add(String item) {
_items.add(item);
notifyListeners();
}
}La faiblesse de Provider apparait a grande echelle. Il est lie a l arbre de widgets, donc tester la logique isolement demande des efforts, et il est facile de reconstruire plus de l arbre que prevu. Pour les petites et moyennes applications je n ai aucune plainte.
Riverpod, ce que je choisis maintenant
Riverpod vient du meme auteur que Provider et corrige la plupart de ses douleurs. L etat vit en dehors de l arbre de widgets, donc vous pouvez le lire sans BuildContext, le tester sans monter de widgets, et attraper les erreurs a la compilation plutot qu a l execution. Les providers sont declares comme variables de haut niveau et vous les observez la ou vous en avez besoin.
import 'package:flutter_riverpod/flutter_riverpod.dart';
final counterProvider = StateProvider<int>((ref) => 0);
class CounterText extends ConsumerWidget {
const CounterText({super.key});
@override
Widget build(BuildContext context, WidgetRef ref) {
final count = ref.watch(counterProvider);
return Text('Compteur a ' + count.toString());
}
}Ce que j aime le plus, c est sa gestion de l async. Un FutureProvider vous donne les etats de chargement, d erreur et de donnees sans ecrire le boilerplate vous meme, ce qui se relie bien au travail reseau que je decris dans debuter avec Flutter. Pour la plupart des nouveaux projets c est mon choix par defaut.
Bloc, quand la discipline compte
Bloc est plus lourd et plus dogmatique. Vous modelisez votre application comme des evenements qui entrent et des etats qui sortent, et la separation stricte rend les grandes equipes previsibles. Chaque changement d etat est un evenement explicite avec un gestionnaire clair, ce qui rend l application facile a tracer et a tester. Le cout est la ceremonie. Les fonctionnalites simples demandent beaucoup de code.
- Provider: peu de ceremonie, lie a l arbre, ideal pour les petites applications
- Riverpod: testable, sur a la compilation, fort support async, mon defaut
- Bloc: verbeux mais previsible, brille sur les grandes equipes et les flux complexes
Comment je decide vraiment
J adapte l outil a l equipe et a l application. Un projet solo ou un prototype recoit Provider ou Riverpod parce que je veux avancer vite. Une grande application avec de nombreux contributeurs et des regles metier complexes recoit Bloc parce que la structure se rentabilise en moins de surprises. La mauvaise decision est de choisir l outil le plus lourd pour le plus petit travail parce qu un article de blog vous a dit que c etait la meilleure pratique.
Gardez l etat hors de la methode build
Quoi que vous choisissiez, une regle tient pour toutes. Ne creez jamais et ne modifiez jamais l etat dans une methode build, car build peut s executer plusieurs fois par seconde et vous creerez des dechets ou declencherez des boucles. Gardez l etat au bon endroit, ecoutez le, et laissez le framework reconstruire. Bien faire cela garde aussi votre application fluide, ce qui rejoint l optimisation des performances Flutter. Reglez bien l etat et la plupart des autres problemes deviennent plus petits.