使用 flutter_bloc 库有什么缺点
What are disadvantages of using flutter_bloc library
BLoC 模式的实现有很多版本。其中之一是 Felix Angelov 的 flutter_bloc。
在其中一个社交媒体上，我看到了 flutter_bloc
不是项目的好选择，应该选择另一个 BLoC 或另一个状态管理。
实际上它是一个小型标准项目，分为 layers:domain、应用程序、基础架构和演示文稿。没什么特别的。
所以抱怨错误选择的人说 flutter_bloc:
- 隐藏实施细节
- 保留一个状态对象（为什么，如果它真的有用那么你就不会这样做），
- 表示使用
mapToState 的首选方式 - 使用 async 生成器而不是流
如果有人可以详细说明此声明并列出使用 flutter_bloc 的真正缺点，我将不胜感激。例如对我来说，第 1 点隐藏实现细节是一个优势，因为我不必直接处理 RxDart。但也许我错过了什么。我没有完全理解第 2 点。
flutter_bloc 通过将输入显式映射到状态来工作，否则无法工作。
我想你朋友所说的“保留状态对象”的意思是任何人在任何时候收听 che BLoC 的实例状态都将返回相同的状态，这与使用 rxDart的BehaviorSubject.
我个人对 flutter_bloc 的看法是，它在复杂场景中可能过于局限，因为它允许创建仅处理一个输入和一个输出的 BLoC。
让我向您展示我在谈到这个问题时给 table 带来的典型例子。
假设您有一个页面，在屏幕的上半部分有一个旋转木马，上面有一些卡片（假设这些是借记卡）。
屏幕的后半部分显示了一个标签，其中包含卡的当前余额和使用该卡进行的付款列表。
假设您需要从响应时间非常不同的两个不同的 API 检索这两条不同的信息（余额将比付款列表快得多）。
对于这种情况，我会使用一个 BLoC 和：
- 卡片列表的输出
stream
- 输入
sink选择卡片
- 输出
stream 平衡
- 支付列表的输出
stream
当滚动轮播时，您将选择的卡片下沉，然后两个小部件（余额和列表）将监听自己的流并相应地更新信息加载状态和数据。
如果你想用 flutter_bloc 做同样的事情，你必须将它分成三个不同的 BLoCs 当然：
BLoC发卡列表BLoC以卡片为输入，余额为输出状态BLoC 以卡片作为输入，支付列表作为输出状态
出于单一责任和可测试性的原因，我们当然可以谈论为三个不同的信息设置三个单独的 BLoC，但是（再次强调，这是我非常非常个人的意见）在某些情况下我认为它最好将相同 page/feature 的内容包装在相同的 BLoC.
中
此外，在某些情况下（不是这种情况），您必须执行 BLoC 到 BLoC 的通信，这意味着 BLoC 依赖于其他 [=14] =]s（在某些情况下有点吓到我）
我喜欢按功能对 BLoC 进行分组。
在上面的例子中，这些都是与借记卡信息屏幕相关的东西，如果我需要导航到一些细节，我可以这样做，将我的所有逻辑集中到一个 BLoC.
如果一个 BLoC 有一部分特征可以在其他 BLoC 中通用，我将在通用 BLoC 中提取它们并使用 BLoC 到 BLoC 交流（如this）.
请注意，由于使用 flutter_bloc 强制 你有多个 BLoC s 即使它可能不是必需的，你会有更高的变化必须执行 BLoC 到 BLoC 的通信。
同样，我们可以说这个答案可能有偏见，因为它突出了我的一些个人观点，所以把它当作一堆考虑因素而不是“法律”。我很乐意收到任何不同意我意见的人的反馈，因为我的 BLoC 哲学仍在进步，我经常对什么是最好的方法感到矛盾！
BLoC 模式的实现有很多版本。其中之一是 Felix Angelov 的 flutter_bloc。 在其中一个社交媒体上，我看到了 flutter_bloc 不是项目的好选择，应该选择另一个 BLoC 或另一个状态管理。
实际上它是一个小型标准项目，分为 layers:domain、应用程序、基础架构和演示文稿。没什么特别的。
所以抱怨错误选择的人说 flutter_bloc:
- 隐藏实施细节
- 保留一个状态对象（为什么，如果它真的有用那么你就不会这样做），
- 表示使用
mapToState的首选方式 - 使用async生成器而不是流
如果有人可以详细说明此声明并列出使用 flutter_bloc 的真正缺点，我将不胜感激。例如对我来说，第 1 点隐藏实现细节是一个优势，因为我不必直接处理 RxDart。但也许我错过了什么。我没有完全理解第 2 点。
flutter_bloc 通过将输入显式映射到状态来工作，否则无法工作。
我想你朋友所说的“保留状态对象”的意思是任何人在任何时候收听 che BLoC 的实例状态都将返回相同的状态，这与使用 rxDart的BehaviorSubject.
我个人对 flutter_bloc 的看法是，它在复杂场景中可能过于局限，因为它允许创建仅处理一个输入和一个输出的 BLoC。
让我向您展示我在谈到这个问题时给 table 带来的典型例子。
假设您有一个页面，在屏幕的上半部分有一个旋转木马，上面有一些卡片（假设这些是借记卡）。 屏幕的后半部分显示了一个标签，其中包含卡的当前余额和使用该卡进行的付款列表。
假设您需要从响应时间非常不同的两个不同的 API 检索这两条不同的信息（余额将比付款列表快得多）。
对于这种情况，我会使用一个 BLoC 和：
- 卡片列表的输出
stream - 输入
sink选择卡片 - 输出
stream平衡 - 支付列表的输出
stream
当滚动轮播时，您将选择的卡片下沉，然后两个小部件（余额和列表）将监听自己的流并相应地更新信息加载状态和数据。
如果你想用 flutter_bloc 做同样的事情，你必须将它分成三个不同的 BLoCs 当然：
BLoC发卡列表BLoC以卡片为输入，余额为输出状态BLoC以卡片作为输入，支付列表作为输出状态
出于单一责任和可测试性的原因，我们当然可以谈论为三个不同的信息设置三个单独的 BLoC，但是（再次强调，这是我非常非常个人的意见）在某些情况下我认为它最好将相同 page/feature 的内容包装在相同的 BLoC.
此外，在某些情况下（不是这种情况），您必须执行 BLoC 到 BLoC 的通信，这意味着 BLoC 依赖于其他 [=14] =]s（在某些情况下有点吓到我）
我喜欢按功能对 BLoC 进行分组。
在上面的例子中，这些都是与借记卡信息屏幕相关的东西，如果我需要导航到一些细节，我可以这样做，将我的所有逻辑集中到一个 BLoC.
如果一个 BLoC 有一部分特征可以在其他 BLoC 中通用，我将在通用 BLoC 中提取它们并使用 BLoC 到 BLoC 交流（如this）.
请注意，由于使用 flutter_bloc 强制 你有多个 BLoC s 即使它可能不是必需的，你会有更高的变化必须执行 BLoC 到 BLoC 的通信。
同样，我们可以说这个答案可能有偏见，因为它突出了我的一些个人观点，所以把它当作一堆考虑因素而不是“法律”。我很乐意收到任何不同意我意见的人的反馈，因为我的 BLoC 哲学仍在进步，我经常对什么是最好的方法感到矛盾！