使用 flutter_bloc 库有什么缺点答案

【问题标题】：What are disadvantages of using flutter_bloc library使用 flutter_bloc 库有什么缺点
【发布时间】：2020-11-18 13:13:39
【问题描述】：

BLoC 模式的实现有很多版本。其中之一是 Felix Angelov 的 flutter_bloc。在其中一个社交媒体上，我看到了 flutter_bloc 的声明对于项目来说不是一个好的选择，应该选择另一个 BLoC 或另一个状态管理。

实际上，这是一个小型标准项目，分为多个层：域、应用程序、基础架构和表示。没什么特别的。

所以抱怨选择错误的人说的是flutter_bloc：

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

【问题讨论】：

【解决方案1】：

flutter_bloc 通过将输入显式映射到状态来工作，否则无法工作。

我想“保留一个状态对象”你的朋友的意思是任何人在任何时候听 che BLoC 的实例状态都会回到相同的状态，这与你使用 rxDart 的 @ 得到的相同。 987654325@.

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

让我向你展示我在谈论这个时提出的典型例子。

假设您在屏幕上半部分有一个带有轮播的页面，其中包含一些卡（假设这些是借记卡）。屏幕的后半部分显示了一个标签，其中包含卡的当前余额以及使用该卡进行的付款列表。

假设您需要从响应时间非常不同的两个不同 api 中检索这两条不同的信息（余额会比付款列表快得多）。

对于这种情况，我会使用 BLoC 和：

当滚动轮播时，你下沉选择的卡片，然后两个小部件（余额和列表）将监听它们自己的流并根据信息加载状态和数据进行相应的更新。

如果您想使用 flutter_bloc 做同样的事情，您肯定必须将其拆分为三个不同的 BLoCs：

出于单一职责和可测试性的原因，我们当然可以谈论为三个不同的信息设置三个单独的 BLoCs，但是（再次，这是我非常非常个人的观点）在某些情况下，我认为最好将同一页面/功能的内容包装在同一 BLoC 中。

另外，在某些情况下（不是这个），您必须执行 BLoC 到 BLoC 的通信，这意味着 BLoCs 依赖于其他 BLoCs（这在某些情况下让我感到害怕情况）

我喜欢组织我的BLoCs，按功能对它们进行分组。

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

如果一个 BLoC 具有在其他 BLoCs 中可以共有的部分功能，我将在通用 BLoC 中提取它们并使用 BLoC 到 BLoC 通信（如 this） .

请注意，由于使用flutter_bloc 强制即使可能没有必要，您也会拥有多个 BLoCs，因此您将不得不执行 BLoC 到 @ 的更高更改987654352@通讯。

再次，我们可以说这个答案可能是有偏见的，因为它是我的一些个人意见，所以把它当作一堆考虑因素而不是“法律”。我很高兴收到任何不同意我的人的反馈，因为我的BLoC 理念仍在进步，我经常对什么是最好的方法感到矛盾！

【讨论】：

嗨，这是一个旧答案，并且已经过去了很多时间。经过深思熟虑后，我转向了flutter_bloc，发现它很棒并且修复了一些“普通方法”问题，如冗长和其他问题。我在这里写过：medium.com/flutter-community/…希望它对这个主题有所帮助
我同意你的观点，太多的 BLoC 不是一个好的设计。对于你的信用卡场景，更简单的设计是一个 BLoC 和 3 个流订阅（简称 ss），即：Card、Balance 和 Transactions。流程如下：用户发送 SelectCardEvent -> 取消所有 3 个 ss -> 初始化 Card ss。在 Card ss 状态更改 -> 初始化 Balance 和 Transactions ss （它将单独获取数据并以自己的速度更新状态）。所以，基本上一个 BLoC 和 3 个 Streams 就足够了。