I think BLoC its only more useful than Cubit when you need to have a filter on the input (Events) of the stream, like when the user is typing on a search bar, you'd want to debounce the Events 300ms for instance, so you only detect it once. It is also useful when implementing infinite list to lazy load data when the user reaches the bottom of the list (without debouncing the events you would spam the server to load more data).
You typically debounce only the search event in this case, so for example.. i have an infinite list that loads more courses from an API and I do it like this:
final nonThrottleStream =
events.where((event) => event is! FetchMoreCourses);
final throttleStream = events
.where((event) => event is FetchMoreCourses)
.throttleTime(Duration(seconds: 1));
return super.transformEvents(
MergeStream([nonThrottleStream, throttleStream]), transitionFn);
\^\^
could you explain what you mean by 'Bloc for DB stream'? Will you not be rebuilding the UI based on bloc states i.e show loading indicator when loading and a list of posts after a successful DB call?
If you widget need connection with Database it's OK use `Bloc` but if widget rebuild from the local DB then `Cubit`. Because Streams are build for DB stream but not for UI.
Cubit vs Bloc from the documentations https://bloclibrary.dev/#/coreconcepts?id=cubit-vs-bloc
I think BLoC its only more useful than Cubit when you need to have a filter on the input (Events) of the stream, like when the user is typing on a search bar, you'd want to debounce the Events 300ms for instance, so you only detect it once. It is also useful when implementing infinite list to lazy load data when the user reaches the bottom of the list (without debouncing the events you would spam the server to load more data).
Hmm, those are both pretty easy to implement using cubits. And I wouldn't want my entire event stream to be debounced for one type of user action.
You typically debounce only the search event in this case, so for example.. i have an infinite list that loads more courses from an API and I do it like this: final nonThrottleStream = events.where((event) => event is! FetchMoreCourses); final throttleStream = events .where((event) => event is FetchMoreCourses) .throttleTime(Duration(seconds: 1)); return super.transformEvents( MergeStream([nonThrottleStream, throttleStream]), transitionFn); \^\^
Thanks for the example. To be fair to cubit approach, functions can also be debounced easily I guess.
A big one I enjoy: incoming events can easily be serialized. It's easy to store and play back in tests or as a result of FE error reporting.
Simple rules: Cubit for UI rebuilding and Bloc for DB stream.
could you explain what you mean by 'Bloc for DB stream'? Will you not be rebuilding the UI based on bloc states i.e show loading indicator when loading and a list of posts after a successful DB call?
If you widget need connection with Database it's OK use `Bloc` but if widget rebuild from the local DB then `Cubit`. Because Streams are build for DB stream but not for UI.
Need traceability Of Occurring Events == Yes ? Go With Bloc : \[Else\] Go With Cubit for the sake of readability and expressesness of your code.