search

jacobaraujo7 / bloc-pattern

Apenas um package com bases para implantar o Bloc no seu Código
MIT License
134 stars 20 forks source link

Use provider package #5

Closed chimon2000 closed 5 years ago

chimon2000 commented 5 years ago

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

jacobaraujo7 commented 5 years ago

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

Bwolfs2 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

think the problem is related to this: https://stackoverflow.com/questions/52249578/how-to-deal-with-unwanted-widget-build

chimon2000 commented 5 years ago

@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 commented 5 years ago

Did u are talking about Consumer?

jacobaraujo7 commented 5 years ago

and... closed!