flutter - 使用 flutter_bloc 库的缺点是什么

Question

BLoC 模式的实现有很多版本。其中之一是 Felix Angelov 的 flutter_bloc。
在其中一个社交媒体上，我看到了 flutter_bloc 的声明
对项目来说不是一个好的选择，应该选择另一个 BLoC 或另一个状态管理。
实际上它是一个小的标准项目，分为多个层:域、应用程序、基础设施和表示。没什么特别的。
所以提示错误选择的人说 flutter_bloc:

隐藏实现细节

保留一个状态对象(为什么，如果它真的是功能性的，那么你就不会这样做)，

暗示使用 mapToState 的首选方式- 使用 async生成器而不是流

如果有人可以详细说明此声明并列出使用 flutter_bloc 的真正缺点，我将不胜感激。例如对我来说 1) 隐藏实现细节是一个优势，因为我不必直接处理 RxDart。但也许我错过了一些东西。我没有完全理解第 2 点。

Answer 1

flutter_bloc通过将输入显式映射到状态来工作，否则无法工作。
我想通过“保留一个状态对象”，你的 friend 意味着任何人在任何时候听 che BLoC 的实例状态都会恢复到相同的状态，这与你使用 rxDart 得到的相同。的 BehaviorSubject .
我对 flutter_bloc 非常个人的看法是它在复杂场景中的局限性太大，因为它允许创建 BLoC s 只处理一个输入和一个输出。
让我向您展示我在谈论这个问题时提出的典型例子。
假设您有一个页面，在屏幕的上半部分有一个旋转木马，上面有一些卡片(假设它们是借记卡)。
屏幕的后半部分显示一个标签，其中包含该卡的当前余额以及使用该卡进行的付款列表。
假设您需要从响应时间非常不同的两个不同 api 中检索这两个不同的信息(余额将比付款列表快得多)。
对于这种情况，我会使用一个 BLoC和:

输出 stream卡片列表

输入 sink选卡用

输出 stream用于平衡

输出 stream付款 list

滚动轮播时，您将选择的卡片下沉，然后两个小部件(余额和列表)将监听自己的流并相应地更新信息加载状态和数据。
如果你想用 flutter_bloc 做同样的事情，你必须把它分成三个不同的 BLoCs当然:

BLoC提供卡片列表

BLoC将卡作为输入，余额作为输出状态

BLoC以卡片作为输入，以支付列表作为输出状态

我们当然可以谈论拥有三个独立的 BLoC出于单一职责和可测试性的原因，对于三个不同的信息，但是(同样，这是我非常非常个人的意见)在某些情况下，我认为最好将相同页面/功能的内容包装在相同的 BLoC 中。 .
另外，在某些情况下(不是这种情况)，您必须执行 BLoC至 BLoC沟通，这意味着拥有 BLoC s 依赖于其他 BLoC s(在某些情况下让我有点害怕)
我喜欢组织我的 BLoC按功能对它们进行分组。
在上面的例子中，这些都是与借记卡信息屏幕相关的东西，如果我需要导航到一些细节，我可以这样做，将所有逻辑集中在一个 BLoC 中。 .
如果一个 BLoC 有一部分可以在其他地方通用的功能 BLoC s 我将在广义 BLoC 中提取它们和 BLoC 一起去至 BLoC通信(如 this )。
请注意，由于使用 flutter_bloc强制你有多个 BLoC s 即使可能没有必要，您也会有更高的更改必须执行 BLoC至 BLoC沟通。
同样，我们可以说这个答案可能有偏见，因为它代表了我的一些个人意见，所以把它当作一堆考虑而不是“法律”。我很乐意收到不同意我的任何人的反馈，因为我的 BLoC哲学仍在进步，我经常对什么是最好的方法感到矛盾!