Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Request - Integrate `provider` package. #354
Is your feature request related to a problem? Please describe.
Describe the solution you'd like
Describe alternatives you've considered
Thanks for reading, and thanks for a good package!
Why don't you guys petition the maintainer of the Provider package to write an extension similar to https://pub.dev/packages/flutter_bloc_extensions? Otherwise what you're asking for is for something with a narrow scope to become more bloated just because?
Or may I suggest you fork bloc and strip out the BlocProvider and then use the Provider package for your DI and BlocBuilder to build up your blocs?
As one who loves using this package, I'm concern that the request put forth will needlessly bloat apps and code bases where the need for another Provider isn't there. So why should I bloat my codebase when I only need BlocProvider because you guys want something that handles everything?
I have discussed this with the team multiple times and have spoken with the maintainer of provider and we have decided that we currently do not wish to add a dependency on provider for the following reasons:
That's not to say that we will never have a dependency on provider but at this point in time we don't feel that it's the right decision.
Hope that makes sense and I really appreciate the feedback and support. Cheers!
referenced this issue
Jun 21, 2019
I never agreed on that, I've been suggesting that
At this point,
I've been fair and purposefully delayed multiple features on
It does not. It works with both.
I'll add that, from my experience on StackOverflow / Slack, the
There's an entire field of missed opportunities by requiring a
final bloc = BlocProvider.of<MyCounterBloc>(context); return RaisedButton( onPressed: bloc.increment, child: BlocBuilder( bloc: bloc, builder: (_, MyCounterState count) => Text(count.value.toString()), ), );
final bloc = Provider.of<MyCounterBloc>(context); final count = Provider.of<MyCounterState>(context); // or using Consumer<MyCounterState> return RaisedButton( onPressed: bloc.increment, child: Text(count.value.toString()), );
The huge difference is that:
That's just a part of the arguments. But these are the most obvious ones.
Felix has brought the topic of integrating with Provider into flutter_bloc many times to our team, even before Google I/O. @rrousselGit you are doing a FANTASTIC job with
That said, every time we have evaluated the integration, we (as a team at BMW) have decided that we do not see fit by having
We would like to keep this conversation open, healthy, positive, and productive. We are always evaluating technology, and trying to do our best to satisfy everyone. Not only provider has been evaluated, there are other many other tools out there that we have decided not to integrate, such as equatable, a package that we have written as well.
We are building
Thank you everyone for participating! You are a fantastic community!
I'm still missing the basis for the decision that provider shouldn't be included in this package. We've ended up with something less flexible, more rigid. Someone will end up forking your repo, strip out all the redundancy, which will basically simplify it. If that happened then that repo would probably end up becoming more popular than this one. Fragmenting the community like that is unnecessary and avoidable.
I'm a strong believer in the wording "Simplicity is the ultimate sophistication", and I don't wish to see neither bloc nor flutter_bloc get overengineered. I'm still not sure what role the new
Ps. I should also say thank you for sharing BMW's code with the community.
Since the decision of not using
I agree with you that having two packages essentially doing the same thing is bad, and I want to avoid competing with that package as much as possible.
@larssn, sorry if I was unclear but the basis for the decision is as follows:
Provider's scope is extremely broad and is even being promoted as a State Management Solution as of recently.
I personally don't understand why provider is trying to be more than a DI library but I respect the author's decisions and try to stay out of it.
Futhermore, provider promotes the use of
I agree that simplicity is key; however, in my opinion, introducing provider would complicated things quite a bit. We would now have to take an API that is trying to solve every problem and put it in a library with a very focused scope.
The part of flutter_bloc which overlaps with provider is the DI. flutter_bloc has very clear specifications which allow for a simplified api. Issues like this will not happen in flutter_bloc because the library is not trying to solve everything allowing us to hide much of the complexity.
As I mentioned before, this was not a hasty decision; we've had many discussions around the topic and carefully considered both sides.
Lastly, as @jorge mentioned, there is nothing currently stopping developers from adding provider as a dependency and using it with flutter_bloc. I'm not sure why you're making it seem like that is not an option.
The change to introduce
I encourage @rrousselGit and others to create their own bindings to fit their needs and hope I clarified our perspective.
Well, to be fair, it is DI. That's all the provider pattern is in a nutshell: IOC. And I think it is a quite simple one at that.
And this kind of redundancy is exactly the problem in my eyes: re-inventing the wheel.
I respect your decision, even though I disagree with it.
Thank you for your time.
edit: Forgot to mention, Google inadvertently advertised for
can you said me please what are you using of
At the moment, when I use
For this reason I prefer that