Skip to content
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

Use provider package #5

Closed
chimon2000 opened this issue Jul 2, 2019 · 13 comments
Closed

Use provider package #5

chimon2000 opened this issue Jul 2, 2019 · 13 comments

Comments

@chimon2000
Copy link

Wondering if it would be worthwhile to use the provider package by @rrousselGit and reduce the scope of this package a bit.

@jacobaraujo7
Copy link
Owner

I appreciate your concern. What features are you talking about?

@Bwolfs2
Copy link
Contributor

Bwolfs2 commented Jul 2, 2019

I believe the bloc_pattern came up to fix the problems we were having with the provider. Problems we've had since when he was just called Provide.

@chimon2000
Copy link
Author

More of a low priority suggestion to use the provider package internally than a concern. On the surface there seems to be some redundancy, and there was recently a discussion on provider as to whether it should implement the block pattern or whether that should be an extension. Feel free to chime in @rrousselGit

@jacobaraujo7
Copy link
Owner

@chimon2000 The bloc_pattern is different internally from the provider. Its structure is based on singletons, and this supplies the need in some types of projects, while the provider supplies the needs in other projects.

@rrousselGit
Copy link

Without me taking any side for the time being, do you mind making a list of why you wanted it to be different?

What are the problems encountered with provider that this package is trying to solve?

@jacobaraujo7
Copy link
Owner

@rrousselGit I would like to talk to you on twitter. But about your question: The bloc_pattern did not come to fix Provider problems, it simply already existed and was growing in parallel. Today we think of a development pattern based on BLoC, and we expanded it with SLIDY (https://github.com/Flutterando/slidy).

@Bwolfs2
Copy link
Contributor

Bwolfs2 commented Jul 2, 2019

With the Provider when it suffers a change in the bloc everyone that heard this bloc is updated, with the bloc_provider + streams it is possible to update field by field without reloading all the fields that are in the bloc.

@Bwolfs2
Copy link
Contributor

Bwolfs2 commented Jul 2, 2019

I know that the provider has had many changes over time, but bloc_pattern came before and it is not worth changing the projects and with Slidy it was much easier to maintain.

This is not a fight to see which is better, but the bloc_pattern for our projects is fitting better than the other packages

@rrousselGit
Copy link

I do not want to force anything 😄

With the Provider when it suffers a change in the bloc everyone that heard this bloc is updated, with the bloc_provider + streams it is possible to update field by field without reloading all the fields that are in the bloc.

Could you argument on that? From my understanding, there's no difference between what bloc_pattern does and a ChangeNotifier.

@jacobaraujo7
Copy link
Owner

jacobaraujo7 commented Jul 2, 2019

@chimon2000
Copy link
Author

@jacobaraujo7 I think the bloc_pattern library is already great as it is. I understand that there are differences internally between how they work. My observation is purely that if they accomplish similar things at a high level (or rather if some of the scope is duplicated), then maybe it's healthy to have a discussion about code reuse.

@Bwolfs2
Copy link
Contributor

Bwolfs2 commented Jul 3, 2019

Did u are talking about Consumer?

@jacobaraujo7
Copy link
Owner

and... closed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants