颤振BLoC - Bloc与Cubit事件驱动的状态管理优势

Question

与Cubit相比，的实际优势是什么？

除了可跟踪性(您也可以在Cubit中实现适当的日志记录)和高级事件转换之外(我想不出库比特所不能做的任何“高级”事件转换，因为始终有一种使用Cubit的方法。如果您使用的是干净的架构，域层可以帮助处理复杂的数据)。

分享和采购活动

这些都是我正在寻找的东西，应该能够与布洛克做，因为这些事情是不可能真的与小熊。然而，这些似乎是不可能的(或者是吗？)因为在Bloc上添加事件需要标识添加事件的实际Bloc。bloc.add(YourEvent())。

此外，事件共享也有争议，因为这可能导致糟糕的体系结构/难以维护。

对于事件源，如果可能的话，我无法在文档中找到(返回到特定的过去状态？)。

我是不是漏掉了什么？

Answer 1

据我所知，当你拥有不变的状态时，可以很容易地逆转到过去的状态，而不管它是块还是肘。拥有不可变状态允许您在需要特定状态时存储状态列表和还原。

集团没有优势比肘，但有相当不同的目的。在肘中，你有action=>response (function=>states)，而在肘中，你有流。

，cubit做不到什么？

例如，在使用(自第7.20号区块起)块时，可以同时处理两个事件，但不能在cubit上同时调用两个函数。

共享事件

您可以在不同的块之间共享事件实现，因为您必须指定事件集实现的内容。

class MyBlocA extends Bloc<MyEvents, StatesA>

class MyBlocB extends Bloc<MyEvents, StatesB>

如果我理解正确，那么您要做的就是在两个不同的块中处理单个事件，这是不可能的，因为事件被发送到特定的区域。所以它需要两个电话：

blocA.add(EventA);
blocB.add(EventA);

根据您的情况，您可以侦听MyBlocA在MyBlocB中的状态。这样，每当出现MyblocB事件时，操作将取决于MyBlocA的状态。

Answer 2

Blocs和Cubits在状态管理方面是相同的，只有一个不同的状态变异：Bloc是事件驱动的，Cubit是方法驱动的。

除了所有这些，就建筑而言，到目前为止并没有什么不同。所有其他的都被上面的克里斯精确地提到了。这取决于开发人员如何以一种对我们来说是可管理的方式来维护状态。