I'm writing a sample demo app comparing various state management techniques.
In one of my examples, I'd like to use BehaviorSubject in a similar way to ValueNotifier.
That is, I have a top level Provider that exposes a BehaviorSubject, and I want my widget class to:
BehaviorSubject to change the valueI tried setting things up like this:
static Widget create(BuildContext context) {
return Provider<BehaviorSubject<bool>>(
builder: (_) => BehaviorSubject<bool>.seeded(false),
child: Consumer<BehaviorSubject<bool>>(
builder: (_, BehaviorSubject<bool> isLoading, __) => SignInPageRxDart(
loading: isLoading,
),
),
);
}
But as expected, I get this exception:
flutter: The following assertion was thrown building Provider<BehaviorSubject<bool>>(dirty, state:
flutter: _DelegateWidgetState#c6182):
flutter: Tried to use Provider with a subtype of Listenable/Stream (BehaviorSubject<bool>).
My next thought was to use a StreamProvider as Stream is an ancestor class of BehaviorSubject.
StreamProvider only gives me access to the bool value (either via a Consumer or Provider.of).
But how can I then access the original BehaviourSubject so that I can change the value?
Not sure if this use case identifies a gap in the Provider APIs. What is the suggested way of using this?
For now, instead of bool you can make a class that contains bool _and_ a reference to the subject.
Now, I've been thinking on multiple occasions about simplifying these use-cases:
Both of these could be easily adapted for StreamController.
Is this something that you'd like?
StoreProvider. Kind of reminds me of redux 馃槄
I can see how that would address this use case, so it's worth considering.
At the same time, there are already 6 different kinds of Providers. And adding another one doesn't make it easier for newcomers to work out what to use.
So it's a balance between supporting more use cases vs cognitive overhead.
Opinions?
Indeed. That's exactly why there's not built-in yet.
I'm not yet decided on what to do.
In any case, these gists works. You can use them in your own app. provider purposefully exposes the right tools to make your own providers if needed.
That said, this issue is what is stopping me from using StreamProvider<FirebaseUser> with firebase_auth.
For context, firebase_auth has a super convenient Stream<FirebaseUser> get onAuthStateChanged API, which is used to decide if the user is signed in or not.
Using this with StreamProvider is nice, because any descendant widget can get FirebaseUser via Provider.of.
But it means that the original FirebaseAuth object is not accessible.
Hence, we need a MultiProvider with a Provider<FirebaseAuth> and a StreamProvider<FirebaseUser>. So more boilerplate code.
So having a way to accessing both the store (FirebaseAuth) and the stream values (FirebaseUser) would be very nice.
Hence, we need a MultiProvider with a Provider
and a StreamProvider . So more boilerplate code.
There's nothing wrong with that.
For now, do that if you can.
BTW for the initial exception, you can do the following in your main.dart:
void main() {
final originalCheck = Provider.debugCheckInvalidValueType;
Provider.debugCheckInvalidValueType = <T>(T value) {
if (value is Subject) return;
originalCheck<T>(value);
}
}
This will consider subjects as a valid value for Provider().
Try add line in main.dart
```
void main() {
Provider.debugCheckInvalidValueType = null; //this
runApp(MyApp());
}
Most helpful comment
Try add line in main.dart
```
void main() {
Provider.debugCheckInvalidValueType = null; //this
runApp(MyApp());
}