Cubit 和 Bloc 有什么区别？

Question

我对 Bloc 的新版本有点困惑：6.0.0，添加了 Cubit 概念，是 bloc 贬值了还是我们可以同时使用它们？

Answer 1

Cubit 是 BLoC 模式包的一个子集，它不依赖于事件，而是使用方法来发出新状态。

因此，我们可以将 Cubit 用于简单状态，并且根据需要我们可以使用 Bloc。

更新：额外比较

选择 Cubit 比选择 Bloc 有很多优势。两个主要好处是：

Cubit 是 Bloc 的子集；因此，它降低了复杂性。 Cubit 消除了事件类。 Cubit 使用 emit 而不是 yield 来发出状态。由于 emit 同步工作，您可以确保在下一行更新状态。

Answer 2

Cubit 适用于简单的状态管理，您只有一种事件可以绑定到状态。而 Bloc 用于复杂的状态管理，您可以在其中将许多事件映射到状态。

例如让我们考虑以下 Cubit

class SimpleCubit extends Cubit<SimpleState> {
  SimpleCubit () : super(InitialState());
  
  void updateState(String stateName){
    emit(NewState(stateName));
  }  

}

现在来看看Bloc

class SimpleBloc extends Bloc<SimpleEvent, SimpleState> {
  SimpleBloc() : super(InitialState()){
    on<SimpleEven1>(_handleEvent1);
    on<SimpleEven2>(_handleEvent2)
  }

  Future<void> _handleEvent1(SimpleEvent event, Emitter<SimpleState1> emit) async {
   // Put your code here
   emit(SimpleState1(event.args))
}

  Future<void> _handleEvent2(SimpleEvent event, Emitter<SimpleState2> emit) async {
   // Put your code here
   emit(SimpleState2(event.args))
}
  
}

要使用 Cubit 实现上述代码，我们需要切换案例（样板）

Bloc 强制您将每个事件映射到一个单独的函数，这在您具有复杂状态时非常有用。

Answer 3

Cubit 非常适合任何应用规模。 None 其中一个比另一个好。

您必须在可追溯性和事件共享与样板之间做出选择。

可追溯性

当您使用 bloc 时，您有一个包含事件的转换：

Transition {
  currentState: AuthenticationState.authenticated,
  event: LogoutRequested,
  nextState: AuthenticationState.unauthenticated
}

当你使用腕尺时它不会

Transition {
  currentState: AuthenticationState.authenticated,
  nextState: AuthenticationState.unauthenticated
}

仅此一项就可以为您提供可追溯性，因为您只需查看日志就知道哪个事件触发了更改。您会看到事件 A 发生了，然后事件 B 发生了。但在实践中，对于肘，您通常可以在没有“标签”的情况下从变化本身推断出可追溯性，因为没有多少动作可以输出这种变化。所以我想说在那个领域 Cubit 获胜，因为额外的可追溯性通常不值得样板成本。

活动分享

本质上，发射一个 Action/Event 然后映射到调用函数，就像直接调用函数一样。唯一的根本变化是当一个行动必须在需要对其做出反应的多个集团之间共享时。如果必须在 bloc 之间共享操作（例如在注销时重置数据），那么 bloc 可以在该区域派上用场。然而，不将一个集团与另一个集团混在一起可能是一种更好的架构模型，也可能不是，这取决于。这是一个判断电话。

我会说 Bloc 在事件共享方面获胜。我还要说的是，事件共享是否是个好主意还有待商榷。

Cubit 和 Bloc 有什么区别？

What is the difference between Cubit and Bloc?

flutter

bloc

可追溯性

活动分享