Are Bloc events the same as Clean Architecture use-cases?

Question

I have this sample code for use cases:

final class AuthUseCases {
  final DataProxy dataProxy;

  const AuthUseCases(this.dataProxy);

  Future<AuthSession> login(TCredential credential) async {
    // a lot of lines here...
  }

  AuthSession logout(AuthSession session) {
    // a few lines here...
  }
}

and I have this sample code for BloC events by using Freezed package:

@freezed
sealed class TmdbEvent with _$TmdbEvent {
  const factory TmdbEvent.login(TCredential credential) = LoginEvent;
  const factory TmdbEvent.logout() = LogoutEvent;
}

class TmdbBloc extends Bloc<TmdbEvent, PageState> {
  // more lines here...
}

So I was asking myself if I could join these classes together because I think BloC events are the same as use-cases. So some questions here:

• is that idea correct?
• how would this new class look like? I'm new with Freezed package
• is it a good idea to keep a single class or have them separate?

Answer 1

Your idea of combining BloC events with use cases is reasonable, as both are concerned with handling business logic and representing actions within your application. However, it's crucial to maintain a clear separation of concerns. While they can share similarities, it's often beneficial to keep them as distinct entities for better code organization and maintainability.

Here's suggestion:

@freezed
abstract class AuthBlocEvent with _$AuthBlocEvent {
  const factory AuthBlocEvent.login(TCredential credential) = LoginEvent;
  const factory AuthBlocEvent.logout() = LogoutEvent;
}

class AuthBloc extends Bloc<AuthBlocEvent, PageState> {
  final DataProxy dataProxy;

  AuthBloc(this.dataProxy) : super(InitialState);

  @override
  Stream<PageState> mapEventToState(AuthBlocEvent event) async* {
    if (event is LoginEvent) {
      // Login logic...
    } else if (event is LogoutEvent) {
      // Logout logic...
    }
  }
}

However, remember that the decision to combine or separate classes depends on factors like code complexity, maintainability, and adherence to the Single Responsibility Principle. If the class becomes too large or complex, it might be beneficial to split it into separate use cases and BloC events for better readability and maintainability.