1. Le problème du ‘Prop Drilling’ et les limites de setState

L’utilisation exclusive de setState() montre rapidement ses limites dès qu’une information doit être partagée entre plusieurs écrans indépendants (comme l’état de connexion de l’étudiant ou le contenu d’un panier d’inscription). Transmettre manuellement ces variables à travers des dizaines de constructeurs de widgets intermédiaires crée un couplage excessif et nuit à la lisibilité du code.

2. Le patron Provider : la référence recommandée par Google

Le package Provider encapsule élégamment le mécanisme natif InheritedWidget de Flutter. Il permet d’injecter des objets métiers au sommet de l’arborescence et de les rendre accessibles en lecture et en écoute à n’importe quel widget enfant descendant, sans couplage direct.

3. Déclaration d’un modèle d’état avec ChangeNotifier

import 'package:flutter/foundation.dart';

class SessionUtilisateurModel extends ChangeNotifier {
    String? _nomUtilisateur;
    bool _estConnecte = false;

    String? get nomUtilisateur => _nomUtilisateur;
    bool get estConnecte => _estConnecte;

    void ouvrirSession(String nom) {
        _nomUtilisateur = nom;
        _estConnecte = true;
        // Notifie tous les widgets abonnés pour redessiner l'UI
        notifyListeners();
    }

    void fermerSession() {
        _nomUtilisateur = null;
        _estConnecte = false;
        notifyListeners();
    }
}

Synthèse pédagogique : La séparation étanche entre la logique métier pure (ChangeNotifier) et les composants visuels de présentation est le secret de la maintenabilité des applications d’entreprise.

PreviousNext