Khi nào nên sử dụng Carrier.of <X> so với Consumer <X> trong Flutter

Tôi vẫn đang xoay quanh các kỹ thuật quản lý nhà nước trong sự rung động và hơi bối rối về việc khi nào và tại sao nên sử dụng Provider.of<X>so với Consumer<X>. Tôi hiểu (tôi nghĩ) từ tài liệu rằng khi chọn giữa hai thứ này, bạn sẽ sử dụng Carrier.of khi chúng tôi muốn truy cập vào dữ liệu, nhưng bạn không cần UI thay đổi. Vì vậy, những điều sau đây (được lấy từ các tài liệu) có quyền truy cập vào dữ liệu và cập nhật giao diện người dùng về các sự kiện mới:

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

Trong khi đó, nơi chúng tôi chỉ cần dữ liệu trên không muốn xây dựng lại với UI, chúng tôi sẽ sử dụng Provider.of<X>với listentham số được đặt thành false, như sau:

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

Tuy nhiên, listenkhông bắt buộc và vì vậy những điều sau đây cũng sẽ chạy:

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

Vì vậy, điều này mang lại cho tôi một vài câu hỏi:

1. Đây có phải là cách chính xác để phân biệt Provider.of<X>và Consumer<X>. Cái cũ không cập nhật UI, cái nào sau?
2. Nếu listenkhông được đặt thành false, widget sẽ được xây dựng lại theo mặc định hoặc không được xây dựng lại? Điều gì nếu listenđược đặt thành true?
3. Tại sao có Provider.oftùy chọn để xây dựng lại giao diện người dùng khi chúng ta có Consumer?

Nó không thành vấn đề. Nhưng để giải thích mọi thứ nhanh chóng:

Provider.oflà cách duy nhất để có được và lắng nghe một đối tượng. Consumer, Selectorvà tất cả các lệnh * ProxyProvider Provider.ofhoạt động.

Provider.ofvs Consumerlà một vấn đề sở thích cá nhân. Nhưng có một vài tranh luận cho cả hai

Nhà cung cấp.of

• có thể được gọi trong tất cả các vòng đời của widget, bao gồm các trình xử lý nhấp chuột và didChangeDependencies
• không làm tăng vết lõm

Khách hàng

• cho phép xây dựng lại các vật dụng chi tiết hơn
• giải quyết hầu hết các trường hợp lạm dụng BuildContext