使用 flutter_bloc 庫有什么缺點

Question

BLoC 模式的實現有很多版本。 其中之一是 Felix Angelov 的 flutter_bloc。 在其中一個社交媒體上，我遇到了這樣的聲明：flutter_bloc 不是項目的好選擇，應該選擇另一個 BLoC 或另一個 state 管理。

實際上，它是一個小型標准項目，分為以下幾層：領域、應用程序、基礎設施和表示。 沒什么特別的。

所以抱怨選擇錯誤的人說的是flutter_bloc：

1. 隱藏實現細節
2. 保留一個 state object （為什么，如果它是真正的功能，那么你不會這樣做），
3. 意味着使用mapToState的首選方式 - 使用async生成器而不是流

如果有人可以詳細說明此聲明並列出使用 flutter_bloc 的真正缺點，我將不勝感激。 例如，對我來說，第 1 點）隱藏實現細節是一個優勢，因為我不必直接處理 RxDart。 但也許我錯過了一些東西。 我沒有完全理解第 2 點。

Answer 1

flutter_bloc通過將輸入顯式映射到狀態來工作，否則無法工作。

我想“保留state對象”對象“您的朋友是指傾聽Che Bloc的實例BehaviorSubject的任何人都會在任何時刻使用同一rxDart 。

我對flutter_bloc非常個人的看法是，它在復雜場景中可能過於受限，因為它允許創建只處理一個輸入和一個BLoC的 BLoC。

讓我向您展示我在談論這個問題時提出的典型例子。

假設您在屏幕上半部分有一個帶有輪播的頁面，其中包含一些卡（假設這些是借記卡）。 屏幕的后半部分顯示了 label，其中包含卡的當前余額以及使用該卡進行的付款列表。

假設您需要從響應時間非常不同的兩個不同 api 中檢索這兩條不同的信息（余額將比付款列表快得多）。

對於這種情況，我會使用一個BLoC ：

• output stream卡片列表
• 卡選擇的輸入sink
• output stream用於平衡
• output stream用於付款清單

滾動輪播時，您下沉選定的卡片，然后兩個小部件（余額和列表）將監聽它們自己的流並根據加載 state 和數據的信息進行相應更新。

如果你想使用 flutter_bloc 做同樣的事情，你肯定必須把它分成三個不同的BLoCs ：

• BLoC為卡片列表提供服務
• BLoC有一張卡作為輸入，余額作為 output state
• BLoC有一張卡作為輸入，付款列表為 output state

出於單一職責和可測試性的原因，我們當然可以談論為三個不同的信息設置三個單獨的BLoC ，但是（再次，這是我非常非常個人的觀點）在某些情況下，我認為將內容包裝起來會更好同一BLoC中的頁面/功能。

另外，在某些情況下（不是這個），您必須執行BLoC到BLoC的通信，這意味着BLoC取決於其他BLoC （在某些情況下這讓我感到害怕）

我喜歡構建我的BLoC ，將它們按功能分組。

在上面的例子中，這些都是與借記卡信息屏幕相關的東西，如果我需要導航到一些細節，我可以這樣做，將所有邏輯集中到一個BLoC中。

如果一個 BLoC 具有在其他BLoC中通用的部分特征，我將在廣義BLoC和 go 中提取它們，並使用BLoC到BLoC通信（像這樣）。

請注意，由於使用flutter_bloc強制您擁有多個BLoC ，即使它可能不是必需的，您將不得不執行BLoC到BLoC通信的更大變化。

同樣，我們可以說這個答案可能有偏見，因為它是我的一些個人意見，所以把它當作一堆考慮因素而不是“法律”。 我很高興收到任何不同意我的人的反饋，因為我的BLoC理念仍在進步，我經常對什么是最好的方法感到矛盾！