-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bloc as an extension for Provider #416
Comments
@timrijckaert I don't like this idea, currently Also respect |
Hmm I think you misunderstood my intention.
|
Hey @timrijckaert I do understand your thought. Keeping the But indeed if you are using |
Hi @timrijckaert 👋 I would love to hear more about your experience with
In general, I believe it's a better developer experience to be able to import In addition, having a layer of abstraction between Lastly, I want to mention that Looking forward to hearing your thoughts! Thanks 👍 |
Hi @felangel and everybody else who commented. Thanks for the quick reply. Let me quickly give you a summary of how we setup our Currently we have different
Besides an
I agree and therefore I feel that since
Isn't that already the case? 🤔 Thanks |
Hey @timrijckaert thanks for the additional info!
Correct me if I'm wrong but isn't ProxyProvider only necessary if the dependencies change? I'm not sure I understand why it's necessary as dependencies such as Dio, UserStorage, etc... should probably not change throughout the application lifecycle. Even though this architecture may work for you, it's not what I would recommend because you end up having things like the http, storage, and db clients accessible from anywhere in the widget tree which makes it very easy to couple your UI with these low level data providers. Instead, I would recommend creating and providing your repositories using the RepositoryProvider and then accessing your repositories in the various parts of your widget tree in order to build the necessary blocs. Since the repositories and their dependencies should not change I don't see a need for ProxyProvider with this approach.
When you strictly use the Provider syntax, under the hood provider uses Instead, the
You're right that you shouldn't use At the end of the day, if this architecture works well for you then definitely keep it up but I personally think most of your observations/critiques stem from the fact that your architecture diverges from bloc library architecture.
Yes but it's bad practice to directly use a transitive dependency because you're assuming that transitive dependency will always be there. Thoughts? |
Ok, this helps to clear up some decisions made in this library for me. Our architecture of our app is still in an early stage so we could use some guidance on best practices. Just some thoughts/questions:
According to the
I don't know if that is the only valid reason to use it, I just really like the syntax of using type params to get a certain dependency?
The reason we provide these lower level objects at the root of our Widget tree is so we can have the scoping for each screen. Right now we only construct the
I don't know if I understand this correctly, could you perhaps have a little sample where the different behaviours are demonstrated?
Same as
True. We could make the While there is definitely a case to be made for the For example we have this Thanks in advance for the many questions. |
@timrijckaert glad I was able to help!
You can definitely use it like that but I don't think it's the most efficient implementation if your dependencies don't ever change. The implementation calls
What I would recommend is not have "ScreenRepositories" but instead think of your repositories as your domain layer. You might have a
If you set
Yes except that is not the default behavior of provider so it's just one example of why I don't want to let developers have to figure that out on their own and instead just make those decisions in the library since it doesn't make sense to use listen: true in the context of the bloc library architecture (the only thing changing is the data flowing through the streams).
If you want to have bloc-specific analytics, then yes. Otherwise, I'd recommend using BlocDelegate for global analytics and then if you want domain layer analytics you can have the repositories have a dependency on the
I would argue that for most cases you should not be passing around top level dependencies and instead you should have the repositories handle the domain layer (interacting with data providers like apis and dbs) and then have the bloc layer handle the application/feature logic. This keeps your architecture clean, making each part reusable.
I would personally have just made the Thanks for the awesome discussion! Let me know if that helps further clarify things 👍 |
Thanks @felangel |
Is your feature request related to a problem? Please describe.
Fist of all thank you for the open discussion (#354 ) about incorporating the
Provider
package inside this package.With the arrival of version
0.19.0
it now includes theProvider
package.I believe this is a step in the right direction for this package.
Still, I would have like to see more overlapping functionality removed from this package.
In our app we are injecting our
BLoC
's solely wîth the use of theProvider
package.We are not using the
BlocProvider
since it does not have this concept ofProxyProvider
which we like.We consume the events emitted with the use of the
BlocBuilder
and theBlocListener
Widgets.Describe the solution you'd like
Only keep the
BLoC
specific widgets inside this package eg:BlocProvider
BlocBuilder
BlocListener
I think all of the other Widgets have an equivalent inside the
Provider
package.If not please correct me.
Describe alternatives you've considered
We are currently using both packages side by side and that works just fine, however it feels like we have two packages trying to accomplish too much of the same thing.
Since Google more or less encourages the use of
Provider
as the sort of default inversion of control package, I would like to see this package as an EXTENSION of theProvider
package.Additional context
Thanks for your massive investment in the Flutter community.
I hope forward for a healthy open minded discussion.
Thanks in advance
Tim
The text was updated successfully, but these errors were encountered: