Is your feature request related to a problem? Please describe.
I have some classes in our app that I pass in a StateNotifier as a dependency. For example:
class RedirectService({required StateNotifier<AuthState> authStateNotifier}) {
The problem is that, this class could accidentally modify this value by calling .state = value. The intent is also unclear because it appears that the RedirectService has read-write access. If another developer is reading the code, they might think it's OK to set the state.
Describe the solution you'd like
An abstract interface called StateListenable<T> that is similar to ValueListenable. It would have all of the listen/read methods of StateNotifierexcept it wouldn't include the methods to set state.
A StateNotifier<T> would implement StateListenable<T>
Then my constructor would change to this:
class RedirectService({required StateListenable<AuthState> authStateListenable}) {
Describe alternatives you've considered
I've considered subclassing StateNotifier and raising an exception if the value is modified, but that feels messy and the intent is unclear. You don't know at compile time that this is unexpected behavior.
I've also considered using ValueListenable, but then I like that state_notifier is not coupled to Flutter.
Is your feature request related to a problem? Please describe. I have some classes in our app that I pass in a
StateNotifieras a dependency. For example:The problem is that, this class could accidentally modify this value by calling
.state = value. The intent is also unclear because it appears that theRedirectServicehas read-write access. If another developer is reading the code, they might think it's OK to set the state.Describe the solution you'd like An abstract interface called
StateListenable<T>that is similar toValueListenable. It would have all of the listen/read methods ofStateNotifierexcept it wouldn't include the methods to set state.A
StateNotifier<T>would implementStateListenable<T>Then my constructor would change to this:
Describe alternatives you've considered I've considered subclassing
StateNotifierand raising an exception if the value is modified, but that feels messy and the intent is unclear. You don't know at compile time that this is unexpected behavior.I've also considered using ValueListenable, but then I like that
state_notifieris not coupled to Flutter.