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
refactor(bloc): add isClosed to Closable interface #3066
Conversation
packages/bloc/lib/src/bloc_base.dart
Outdated
/// An interface for hooks of the [BlocBase]. | ||
/// | ||
/// Contains the `onChange` and `onError` hooks. | ||
abstract class BlocBaseHooks<State> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the benefit of introducing this interface? I don't like the name hooks
because it can be confused with flutter_hooks
and I also would prefer not to define interfaces unnecessarily. Is there a concrete use-case you had in mind which required operating on this interface specifically?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the benefit of introducing this interface?
The main benefits align with those that ISP and DIP brings — other object can implement the lifecycle calls more easily, other object interested only in lifecycle calls can depend only on desired parts, making code more loosely coupled.
I don't like the name hooks because it can be confused with flutter_hooks and I also would prefer not to define interfaces unnecessarily.
Totally agree, the name can be confusing. LifecycleObserver
sounds good!
Is there a concrete use-case you had in mind which required operating on this interface specifically?
Yes, I was implementing a custom, project-specific version of Bloc that needed some of the "on.." methods, and had to either just hard-code them in the implementation, or extend/implement the BlocBase, but not all methods was desired.
Those interfaces would allow to unify lifecycle calls.
On the other hand, I agree that non-essential interfaces can be redundant and open to discard them if you think that it's too much :)
Also, what constitutes a hook? I would expect onCreate, onClose, etc. to also be included.
I agree, they should be also included if we decide to keep the interfaces!
Closable
interface & apply DIP
Closes #3065
Status
READY
Breaking Changes
NO
Description
There are three main changes done in the following PR. All of them are targeted to extend the recent "core interfaces" update to further apply the Interfaces Segregation and Dependency Inversion principles.
Refer to #3065
Type of Change