Expose the .state, .listenSelf, etc. methods in Ref

[mdyatlov]

Is your feature request related to a problem? Please describe.

Several low-level methods that were previously exposed in riverpod 2, such as .state and .listenSelf were very useful for creating extensions on Ref, such as FutureProviders conditional caching (based on the current AsyncValue), reloading depending on the network availability etc.

In riverpod 3, the unique Ref replaced all the previous Refs (such as FutureProviderRef), and does not expose .state, .listenSelf or other low-level methods.

For example, the cache data for a specific duration extension (code given below) which was fully based on these methods exposed in the riverpod 2 API, becomes incompatible with riverpod 3, leading to a lost of several really useful applications.

extension CacheDataForExtension<T> on AutoDisposeFutureProviderRef<T> {
	void cacheDataFor(Duration duration) {
    var link = keepAlive();
    var timer = Timer(duration, link.close);

    onDispose(() {
      timer.cancel();
    });

    listenSelf((_, newAsyncValue) {
      if (newAsyncValue is AsyncError<T>) {
        timer.cancel();
        link.close();
      } else if (newAsyncValue is AsyncData<T>) {
        timer.cancel();
        link.close();

        link = keepAlive();
        timer = Timer(duration, link.close);
      }
    });
	}
}

Describe the solution you'd like
Re-expose .state and .listenSelf on Ref, or provide equivalent public APIs so that extensions like riverpod_community_extension can keep working without relying on internals.

Describe alternatives you've considered

A possible workaround would be replacing FutureProviders by AsyncNotifiers in this case, but it does not have a strict reasoning as the caching or any other functionalities do not make the Provider modifiable, though not giving a reason for it to become a Notifier.

Additional context

riverpod_community_extension was designed to extend Riverpod’s API in a clean way. These methods were essential for that goal, and their removal breaks valid use cases outside Riverpod’s core.

P.S. I have found that this question was already posted here but for the version 2.6.1 when these methods were deprecated, not removed. I find it pertinent though to relaunch on this question.
#3901

[rrousselGit]

Those methods disappeared because Ref is no-longer a generic object. There's no way to define ,state/.listenSelf without this generic parameter.

Those functionalities are available on Notifier instead. Instead of extension on Ref you can write extension on AnyNotifier. This will achieve the same effect.

[MaximeRougieux]

@rrousselGit I'm not sure to fully understand the reason why Ref was changed to not be generic, but I can imagine it helped to make the library better and easier to maintain, and you're right that the behavior described above can be achieved through an AnyNotifier extension now.

It's just kind of a bummer that there is now no "clean" way of implementing a AsyncData-only cache for FutureProvider (which is still the go-to option when making a simple http call as per the docs) as in the example @mdyatlov gave.

Right now, we have multiple codebases relying hugely on this pattern, so it effectively means we'd have to convert a ton of FutureProviders to AsyncNotifiers if we want to keep this extension working (and others that are alike).

I understand it would be hard (and probably a bad idea) to go back in a way that .state/.listenSelf are available again, but do you have any idea how we could reimplement the same behavior, without having to rely on Notifiers ?

Best I could tinker is using a Family as an intermediary to act as a cache, but I'm not confident about using a ProviderListenable as an argument for a Family

@riverpod
AsyncValue<T> withDataCache<T>(
  Ref ref,
  ProviderListenable<AsyncValue<T>> source, {
  Duration duration = const Duration(seconds: 10),
}) {
  final currentValue = ref.watch(source);

  if (currentValue is AsyncError<T>) {
    return currentValue;
  }

  final link = ref.keepAlive();
  final timer = Timer(duration, link.close);

  ref.onDispose(() {
    link.close();
    timer.cancel();
  });

  return currentValue;
}

@riverpod
Future<int> _counter(Ref ref) async {
  await Future.delayed(const Duration(seconds: 3));

  return 42;
}

final counterProvider = withDataCacheProvider(_counterProvider);

[rrousselGit]

Converting FutureProvider to AsyncNotifier is by design

The naming is unfortunate, but those are the same thing. The latter just has more options.

Think Stateless vs StatefulWidget.

[MaximeRougieux]

Understood, thanks for the explanation