使用 Flutter Provider 意味着沒有 StatefulWidgets？

Question

我准備用 Flutter 和 Provider 編寫我的第一個重要應用程序。 我已經閱讀了 Provider 如何促進不可變小部件（StatelessWidgets）。 我的問題是，在使用 Provider 時使用 StatefulWidgets總是一種反模式嗎？ 如果不是，那么在 Provider 應用程序中最好使用 StatefulWidgets 的例子有哪些？

編輯

使用 Provider 已經幾個月了，在任何情況下我仍然喜歡它而不是 StatefulWidgets。 我時不時地引入一個StatefulWidget，主要是為了嘗試熟悉它們，幾乎立即后悔並重構為Provider。 前幾天我遇到了不刷新的小部件，因為它們是相同的類型，所以正在考慮引入鍵以便它們刷新。 前幾次嘗試失敗了，所以我重構為 Provider 並且一切正常（不需要密鑰）。

反模式在我的 OP 中不是正確的術語。 我想我的問題是，有沒有 StatefulWidgets 更干凈或更容易/更好用的例子？

Answer 1

provider不關心你是寫無狀態/有狀態還是其他任何東西（鈎子？）。

它消除了在許多情況下編寫StatefulWidget的需要，但它並不聲稱您應該只使用StatelessWidget 。

最后，決定是否需要StatefulWidget是您的工作。 例如，您在編寫動畫時可能需要它。

Answer 2

添加到 Rémi 的答案和此實現的新內容：

• 將 Provider 用於共享模型
• 在需要時使用小部件狀態來管理特定於該問題的模型
• 想象一個用戶對象在身份驗證之后，之前為 null，通過應用程序共享，具有特定於編輯字段的狀態的表單，例如昵稱或其他任何內容，更新本地狀態並可能傳播到產品的其余部分（完成更新時）后端？...誰知道），當不再需要該視圖時，該狀態將被處理，但用戶引用仍然通過提供者引用。 管理提供者模型中的所有狀態變化是沒有意義的——這就是結果的去向。

根據我在 React+Redux 以及圍繞原生 Web 組件（類似於這兩個生命周期）和 LitElement 傳遞對象的經驗，在這里做出一些假設。 到目前為止，即使不相同，這些模式似乎也相似。

Answer 3

Provider.of<ProviderClass>(context, listen: false);

Provider 是 Fl​​utter 擁有的一種狀態管理機制，在底層，Provider 會跟蹤在小部件內部完成的更改。 對於 Provider 來說，它是無狀態小部件還是有狀態小部件並不重要，如果有任何變化，它會重建小部件。

listen: false告訴 Provider 即使數據被修改也不要重建小部件。 這意味着它只能在父小部件被 setState() 修改或ProviderClass類值被修改時重新構建。