Callable Future Provider

[josh-burton]

I feel like Riverpod is missing a crucial provider type - a callable future provider. i.e. a Future provider that only executes when called via a call or submit method.

This is a use case I encounter often, and currently I need to create custom StateNotifierProvider classes for each future I want to call.

Ideally we'd be able to define a provider something like this:

static CallbableFutureProvider<Response,Params> myCallableProvider = CallbableFutureProvider(onCall: (ref, params) async {
  return ref.read(apiProvider).callApi(params);
});

It would expose an AsyncValue (or variant as a extra state for 'not yet called' may be needed);

// reading the result any time
final AsyncValue<Response> result = ref.watch(myCallableProvider);

// triggering the callable future 
final onTap = () {
   AsyncValue<Response> result =  ref.read(myCallableProvider).call(params);
}

[rrousselGit]

Hello!

I don't like the idea, as this is too specific. Maybe it'd help if you could explain the use-case behind this?

[rrousselGit]

I need to know more about the issue. Why are you making a FutureProvider for what appears to be a side-effect?

[josh-burton]

I guess primarily so I can watch the loading state of that API call and update progress spinners in the app.

How do you define a 'side effect' and how would you suggest performing that kind of API call?

[rrousselGit]

The upcoming code generator is supposed to solve such a thing

Without it, you have to do things yourself. There's otherwise nothing built-in

[josh-burton]

ok. IMO it would be nice to have something built in for this that doesn't rely on code generation. I think its a common enough use case.

[rrousselGit]

There's no neat syntax for doing this without code-gen. Your suggestion is too specific and wouldn't scale for the variety of use-cases.
For example it's common to pass parameters to that side-effect. So call() isn't enough

For what it's worth, you can conditionally watch providers.
So you can have a stateful widget and do:

build(context, ref) {
  AsyncValue<T>? value;
  if (clicked) value = ref.watch(mySideEffectProvider);
}

This way, the provider will be triggered only when clicked is true.

[samderlust]

@rrousselGit I come across this problem and more specifically with FutureProvider.family. For example:

I have a future provider declare:

  static final registerFuture =
      FutureProvider.family.autoDispose<User, RegisterPayload>((ref, payload) {
    final future = ref.read(RepoProvider.authRepo).register(payload);
    return future;
  });

Now in my widget, I want to call for register after user finishes the form and click sign up

          TextButton(
            onPressed: () async {
              if (formKey.currentState!.validate()) {
                ref.read(AuthProvider.registerFuture(registerPayload.value));
              }
            },
            text: 'Sign Up',
          ),

but also, I want to render my widget according to the current state of the async value for showing loading or error or done. This is when I can not write:

  @override
  Widget build(BuildContext context, WidgetRef ref) {
   final registerFuture =  ref.watch(AuthProvider.registerFuture); // I can not do this
   
  return registerFuture.when()

[TimWhiting]

I think you want #1660

For now, sometimes I do something like this:

 @override
  Widget build(BuildContext context, WidgetRef ref) {
   final register = useState(false); // If using hooks, otherwise do a stateful widget + setstate
   AsyncValue<User>? registerFuture;
   if (register.value) {
      registerFuture =  ref.watch(AuthProvider.registerFuture(registerPayload.value));
   }
   return Column(children: [
     TextButton(
            onPressed: () async {
              if (formKey.currentState!.validate()) {
                register.value = true;
                ref.invalidate(AuthProvider.registerFuture(registerPayload.value)); // or ref.refresh
              }
            },
            text: 'Sign Up',
          ),
     ... loading etc depending on whether the user has triggered the side affect, and what the value of the side effect is.
  ]);
}

However, if it get's any more complicated I would suggest you model the states that this could be in using a StateNotifier/ChangeNotifier, and have register be a method on that.

[samderlust]

yeah. I am using StateNotifier for that. however, I want to use FutureProvider since it just less to do for some thing like this.

[samderlust]

@TimWhiting Do you think that we should put

   AsyncValue<User>? registerFuture;
   if (register.value) {
      registerFuture =  ref.watch(AuthProvider.registerFuture(registerPayload.value));
   }

into a useEffect to avoid unnecessary reassign and rebuild?

[samderlust]

#1660 is definitely what I'm looking for. This would be huge change on we work with FLutter.

Can I use it on master branch?

[TimWhiting]

No, riverpod 2.0 is aiming to come out by the end of the month, and #1660 is tagged for the 2.1 or later release.

Unfortunately, if you don't call ref.watch() on every build, then riverpod will automatically detect that the widget no longer cares about the result of the provider and will dispose it if you have it marked as autoDispose, so it depends on if you are using autoDispose for this provider.