有许多实现BLoC模式的版本。其中之一是Felix Angelov的flutter_bloc。 在一种社交媒体上，我遇到了关于flutter_bloc的声明 对于该项目而言，它不是一个好选择，而应选择另一个BLoC或另一个状态管理。
实际上，这是一个小型的标准项目，分为领域，应用程序，基础结构和表示层。没什么特别的。
所以抱怨选择错误的那个人说的是flutter_bloc：
mapToState的一种首选方式-使用async生成器而不是流如果有人可以详细说明此声明并列出使用flutter_bloc的真正缺点，我将不胜感激。例如，对我来说，点1）隐藏实现细节是一个优势，因为我不必费心处理RxDart。但是也许我缺少一些东西。我没有完全得到第2点。
答案 0 :(得分：3)
flutter_bloc通过将输入显式映射到状态来工作，否则无法工作。
我认为，通过“保留状态对象”，您的朋友的意思是任何在任何时候收听che BLoC实例状态的人都将返回相同的状态，这与您使用rxDart'获得的相同状态s BehaviorSubject。
我对flutter_bloc的个人看法是，在复杂的情况下它可能会过于局限，因为它允许创建仅处理一个输入和一个输出的BLoC。
让我为您展示我在谈论这个话题时所举的典型例子。
假设您在屏幕的上半部分有一个带有轮播功能的页面，上面有一些卡（假设这些卡是借记卡）。 屏幕的后半部分显示带有该卡当前余额的标签以及使用该卡进行的付款清单。
让我们说，您需要从两个具有不同响应时间的api中检索这两个不同的信息（余额远比付款清单快）。
在这种情况下，我将使用一个BLoC和：
stream用于卡片列表sink进行卡选择stream保持平衡stream用于付款清单滚动轮播时，下沉选定的卡，然后这两个小部件（余额和列表）将侦听它们自己的流，并相应地更新为信息加载状态和数据。
如果您想使用flutter_bloc进行相同的操作，则必须将其拆分为三个不同的BLoCs：
BLoC来提供卡片列表BLoC，其中有一张卡片作为输入，其余部分则作为输出状态BLoC，其中有一张卡作为输入，而付款清单则作为输出状态我们可以肯定地说，出于单一责任和可测试性的原因，要针对三种不同的信息使用三个单独的BLoC，但是（再次，这是我非常非常个人的看法）在某些情况下，我认为最好将相同页面/功能的内容包装在同一BLoC中。
此外，在某些情况下（不是这样），您必须执行BLoC到BLoC的通信，这意味着有BLoC个依赖于其他BLoC的通信s（在某些情况下有点吓到我了）
我喜欢将BLoC的每个功能进行分组。
在上述情况下，所有这些都是与借记卡信息屏幕相关的，如果我需要导航至一些详细信息，则可以将所有逻辑集中在一个BLoC中。
如果BLoC具有部分其他BLoC可以共有的功能，则将其提取为广义的BLoC，然后将BLoC移至{{1} }通信（例如this）。
请注意，由于使用BLoC 强制，即使没有必要，您也会拥有多个flutter_bloc，因此必须执行{ {1}}至BLoC通信。
同样，我们可以说这个答案可能是有偏见的，因为它标明了我的一些个人观点，因此应将其视为一整套考虑因素，而不是“法律”。我很高兴收到不同意我的人的反馈，因为我的BLoC哲学仍在进步，而且我常常对最佳方法感到矛盾！