Provider: [Question] Using BehaviorSubject with Provider

Created on 12 Jul 2019  路  7Comments  路  Source: rrousselGit/provider

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:

  • have access to the BehaviorSubject to change the value
  • be rebuilt when the value changes

I 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?

Most helpful comment

Try add line in main.dart

```
void main() {
Provider.debugCheckInvalidValueType = null; //this

runApp(MyApp());
}

All 7 comments

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());
}

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Vadaski picture Vadaski  路  3Comments

arnoutvandervorst picture arnoutvandervorst  路  4Comments

mhd-barikhan picture mhd-barikhan  路  5Comments

dikir picture dikir  路  5Comments

stocksp picture stocksp  路  5Comments