Cuándo usar Provider.of <X> vs. Consumer <X> en Flutter

Todavía estoy envolviendo mi cabeza alrededor de técnicas de control del estado en el flúter y estoy un poco confundido acerca de cuándo y por qué utilizar Provider.of<X>vs Consumer<X>. Entiendo (creo) de la documentación que al elegir entre estos dos usaría el proveedor de cuando queremos acceder a los datos, pero no necesita cambiar la interfaz de usuario. Entonces, lo siguiente (tomado de los documentos) obtiene acceso a los datos y actualiza la IU en nuevos 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}');
      },
    ),
  ),
);

Mientras que donde solo necesitamos los datos no queremos reconstruir con la interfaz de usuario, los usaríamos Provider.of<X>con el listenconjunto de parámetros falsecomo se muestra a continuación:

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

Sin embargo, listenno es obligatorio, por lo que también se ejecutará lo siguiente:

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

Esto me lleva a algunas preguntas:

1. ¿Es esta la forma correcta de distinguir Provider.of<X>y Consumer<X>. El primero no actualiza la interfaz de usuario, ¿el último sí?
2. Si listenno se establece en false¿se reconstruirá el widget por defecto o no se reconstruirá? ¿Qué pasa si listense establece en true?
3. ¿Por qué tener Provider.ofla opción de reconstruir la interfaz de usuario cuando tenemos Consumer?

No importa. Pero para explicar las cosas rápidamente:

Provider.ofes la única forma de obtener y escuchar un objeto. Consumer, SelectorY todas las llamadas * ProxyProvider Provider.ofa trabajar.

Provider.ofvs Consumeres una cuestión de preferencia personal. Pero hay algunos argumentos para ambos

Proveedor de

• se puede llamar en todos los ciclos de vida de los widgets, incluidos los controladores de clics y didChangeDependencies
• no aumenta la sangría

Consumidor

• permite reconstrucciones de widgets más granulares
• resuelve la mayoría del mal uso de BuildContext