Quand utiliser Provider.of <X> contre Consumer <X> dans Flutter

J'emballage toujours ma tête autour des techniques de gestion de l' Etat en flottement et je suis un peu confus quand et pourquoi utiliser Provider.of<X>contre Consumer<X>. Je comprends (je pense) de la documentation que lorsque vous choisissez entre ces deux, vous utiliseriez Provider.of lorsque nous voulons accéder aux données, mais vous n'avez pas besoin de l'interface utilisateur pour changer. Ainsi, les éléments suivants (extraits des documents) ont accès aux données et mettent à jour l'interface utilisateur sur les nouveaux événements:

return HumongousWidget(
  // ...
  child: AnotherMonstrousWidget(// <- This widget will rebuild on new data events
    // ...
    child: Consumer<CartModel>(
      builder: (context, cart, child) {
        return Text('Total price: ${cart.totalPrice}');
      },
    ),
  ),
);

Alors que, lorsque nous n'avons besoin que des données sur ne veulent pas reconstruire avec l'interface utilisateur, nous utiliserions Provider.of<X>avec le listenparamètre défini sur false, comme ci-dessous:

Provider.of<CartModel>(context, listen: false).add(item); \\Widget won't rebuild

Cependant, ce listenn'est pas obligatoire et donc ce qui suit s'exécutera aussi:

Provider.of<CartModel>(context).add(item); \\listener optional

Cela m'amène donc à quelques questions:

1. Est-ce la bonne façon de distinguer Provider.of<X>et Consumer<X>. L'ancien ne met pas à jour l'interface utilisateur, le dernier le fait?
2. S'il listenn'est pas défini sur false, le widget sera-t-il reconstruit par défaut ou non reconstruit? Et si listenest réglé sur true?
3. Pourquoi avoir Provider.ofl'option de reconstruire l'interface utilisateur quand nous l'avons Consumer?

Ça n'a pas d'importance. Mais pour expliquer les choses rapidement:

Provider.ofest le seul moyen d'obtenir et d'écouter un objet. Consumer, SelectorEt tous les appels * de ProxyProvider Provider.ofau travail.

Provider.ofvs Consumerest une question de préférence personnelle. Mais il y a quelques arguments pour les deux

Provider.of

• peut être appelé dans tout le cycle de vie des widgets, y compris les gestionnaires de clics et didChangeDependencies
• n'augmente pas le retrait

Consommateur

• permet de reconstruire des widgets plus granulaires
• résout la plupart des utilisations abusives de BuildContext