使用flutter_bloc库有哪些缺点？

Question

BLoC模式的实现有许多版本。其中之一是费利克斯·安吉洛夫( Felix )的flutter_bloc。在一种社交媒体上，我发现flutter_bloc不是项目的好选择，应该选择另一种BLoC或另一种状态管理。

实际上，它是一个小的标准项目，分为层次:域、应用程序、基础设施和表示。没什么特别的。

因此，抱怨错误选择的人说，flutter_bloc：

1. 隐藏实现细节
2. 保留状态对象(为什么，如果它是真正的功能，那么您就不会这样做)，
3. 意味着使用mapToState的首选方法--使用async生成器而不是流。

如果有人能详细说明这一声明，并列出使用flutter_bloc的真正缺点，我将非常感激。例如，对我来说，隐藏实现细节是一个优势，因为我不需要直接处理RxDart。但也许我遗漏了什么。我没有完全理解第2点。

Answer 1

flutter_bloc的工作方式是显式地将输入映射到状态，否则不能工作。

我想，“保留一个状态对象”是指，任何在任何时候听che组实例状态的人都会返回相同的状态，这与使用rxDart's BehaviorSubject获得的状态相同。

我个人对flutter_bloc的看法是，它在复杂的场景中可能过于有限，因为它允许创建只处理一个输入和一个输出的BLoC。

让我给你们展示一下我在讨论这件事时带来的典型例子。

假设您有一个页面，在屏幕的上半部分有一个旋转木马，上面有一些卡片(假设这些是借记卡)。屏幕的后半部分显示了卡当前余额的标签和用该卡支付的列表。

假设您需要从具有非常不同响应时间的两个不同apis中检索这两个不同的信息(余额将比支付列表快得多)。

在这种情况下，我会使用一个BLoC和：

• 输出卡片列表的stream
• 输入sink进行卡片选择
• 输出stream用于平衡
• 支付列表的输出stream

当滚动旋转木马时，您将接收所选的卡片，然后这两个小部件(balance和list)将侦听它们自己的流，并相应地更新信息加载状态和数据。

如果您想使用flutter_bloc做同样的事情，那么您肯定需要将它分成三个不同的BLoCs：

• BLoC提供卡片列表
• 以卡片作为输入，余额作为输出状态的BLoC
• 以卡片作为输入，付款列表作为输出状态的BLoC

出于单一责任和可测试性的原因，我们当然可以为这三种不同的信息讨论三个单独的BLoC，但是(同样，这是我非常非常个人的观点)在某些情况下，我认为最好在同一个BLoC中包装相同页面/特性的内容。

另外，在某些情况下(不是这种情况)，您必须执行BLoC到BLoC通信，这意味着BLoC依赖于其他BLoC(在某些情况下这会让我感到害怕)。

我喜欢将我的BLoC按特性分组。

在上面的例子中，这些都是与借记卡信息屏幕相关的东西，如果我需要导航到一些细节，我可以将我的所有逻辑集中到一个BLoC中。

如果一个BLoC有一些可以在其他BLoC中通用的特性，我将在一个通用的BLoC中提取它们，并与BLoC到BLoC通信一起使用(比如这)。

注意，由于使用flutter_bloc会迫使您拥有多个BLoC，即使它可能不是必要的，因此您将不得不执行BLoC到BLoC通信，这将带来更大的变化。

同样，我们可以说这个答案可能是有偏见的，因为它突出了我的一些个人观点，所以把它当作一堆考虑因素，而不是“法律”。我很乐意从不同意我的人那里得到一些反馈，因为我的BLoC哲学仍然在进步，而且我经常对什么是最好的方法感到矛盾！