For example, I have 3 features.
In normal cases, we create bloc like this.
But I want only to create 1 state, so the expectation is like this.
First, I create 1 state namely custom_state.dart. So on the other feature is like this.
We can see, we don't create any state for all features. But only crate bloc and event. So in the all bloc class is like this.
class LoginBloc extends Bloc<LoginEvent, CustomState>
class RegisterBloc extends Bloc<RegisterEvent, CustomState>
class BannerBloc extends Bloc<BannerEvent, CustomState>
class ProductBloc extends Bloc<ProductEvent, CustomState>
It's possible?
Hi @rrifafauzikomara 馃憢
That is possible to do, but I'd highly recommend having a bloc per feature.
And when I say it's possible I mean to use the same type as state, but each bloc would have it's own instance of it, so if you're looking to share the same instance that is not achievable like that.
With the setup that you want to work with, you'd definitely break the single responsibility principle and clutter your bloc.
I think I have the similar issue,
It happens that some states and even some events are common to some features, and we need to have some common states and events among different type of blocs.
For example for me the ServerIsNotAvailable state occurred in different blocs while communication with the server is not available.
Hi @narcodico
That is possible to do, but I'd highly recommend
having a bloc per feature.
So, you mean on the home page for handling banner and product should 1 BLoC. Or you mean every BLoC should have even, bloc, and state (Can't using 1 state for all bloc)?
Because I thinking about a sealed class on Android Native (Kotlin). We can create BaseResponse like Loading, Error, HasData, NoData using that class. And then on the logic layer ex: ViewModel, every result is using that class for every result on ViewModel on all features. And when I see the structure of this package, I think the state it looks like BaseResponse in the Native. Because I used that for handing Loading, Error, HasData, NoData. But for now, every feature and bloc have state and inside it have the same type (Loading, Error, HasData, NoData). So I just curious, it's possible to use 1 state for handling Loading, Error, HasData, NoData for all bloc on all features?
This is the implementation for every bloc that has the same type as a state. https://github.com/rrifafauzikomara/MovieApp/tree/master/core/lib/src/bloc
@omidraha
It happens that some
statesand even someeventsare common to some features, and we need to have some commonstatesandeventsamong different type ofblocs.
I'd recommend keeping events and states tied to your bloc, even if that results in a bit of code duplication, since that way you'd end up keeping your blocs completely decoupled. I think it makes sense to have a generic approach to this only if you need multiple blocs, all with the exact same states/events but a different data type.
For example for me the
ServerIsNotAvailablestate occurred in differentblocswhile communication with the server is not available.
I feel that you should have a different setup. Maybe have a single failure state which would contain a field indicating the reason for the failure. e.g:
enum FailureType { serverNotAvailable, unexpected }
class AuthFailure extends AuthState {
final FailureType failureType;
}
class LoginFailure extends LoginState {
final FailureType failureType;
}
Obviously the field could be a class containing additional info if needed, I made it as an enum for the sake of showcasing my point.
@rrifafauzikomara
So I just curious, it's possible to use 1 state for handling
Loading, Error, HasData, NoDatafor all bloc on all features?
As mentioned, nobody stops your from having the same state type used on multiple blocs, but each bloc will have it's own current state instance.
Most helpful comment
@omidraha
I'd recommend keeping events and states tied to your bloc, even if that results in a bit of code duplication, since that way you'd end up keeping your blocs completely decoupled. I think it makes sense to have a generic approach to this only if you need multiple blocs, all with the exact same states/events but a different data type.
I feel that you should have a different setup. Maybe have a single failure state which would contain a field indicating the reason for the failure. e.g:
Obviously the field could be a class containing additional info if needed, I made it as an enum for the sake of showcasing my point.
@rrifafauzikomara
As mentioned, nobody stops your from having the same state type used on multiple blocs, but each bloc will have it's own current state instance.