Quando usar Provider.of <X> vs. Consumer <X> no Flutter

Eu ainda estou quebra minha cabeça em torno de técnicas de gerenciamento de estado em vibração e estou um pouco confuso sobre quando e por que usar Provider.of<X>vs. Consumer<X>. Entendo (acho) a partir da documentação que, ao escolher entre esses dois, você usaria Provider.of quando quisermos acessar os dados, mas você não precisará alterar a interface do usuário. Portanto, o seguinte (extraído dos documentos) obtém acesso aos dados e atualiza a interface do usuário em novos eventos:

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}');
      },
    ),
  ),
);

Considerando que, onde apenas precisamos dos dados e não queremos reconstruir com a interface do usuário, usaríamos Provider.of<X>com o listenparâmetro definido falsecomo, como abaixo:

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

No entanto, listennão é necessário e, portanto, o seguinte também será executado:

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

Então, isso me leva a algumas perguntas:

1. Essa é a maneira correta de distinguir Provider.of<X>e Consumer<X>. A versão anterior não atualiza a interface do usuário, a última?
2. Se listennão estiver definido como false, o widget será reconstruído por padrão ou não será reconstruído? E se listenestiver definido como true?
3. Por que ter Provider.ofa opção de reconstruir a interface do usuário quando temos Consumer?

Não importa. Mas para explicar as coisas rapidamente:

Provider.ofé a única maneira de obter e ouvir um objeto. Consumer, SelectorE todas as chamadas ProxyProvider * Provider.ofao trabalho.

Provider.ofvs Consumeré uma questão de preferência pessoal. Mas há alguns argumentos para ambos

Provedor.de

• pode ser chamado em todo o ciclo de vida dos widgets, incluindo manipuladores de clique e didChangeDependencies
• não aumenta o recuo

Consumidor

• permite reconstruir widgets mais granulares
• resolve a maioria dos usos indevidos do BuildContext