Accessing cached state for conditional refresh validation with persist()

[pckimlong]

Long time ago I did implement a custom riverpod offline support for an app. But now since riverpod has that built-in I want to migrate to official API. But somehow it not allow me to easy maintain existing logic. My old implementation allow to check custom criterial on cached data to decide whether to refresh:

@riverpod
class RadioList extends _$RadioList {
  @override
  FutureOr<IList<RadioModel>> build() {
    const staleDuration = Duration(hours: 6);

    return persistState(
      fetchFreshData: () async { /* ... */ },
      fetchPersistedData: () async { /* ... */ },
      persistData: (data) async { /* ... */ },
      shouldFetchFreshData: (persistedData) async {
        final cache = ref.read(cacheManagerProvider);
        final time = await cache.readDateTime(cachedStaleKey);

        final isStale =
            persistedData.isEmpty ||
            time == null ||
            time.isBefore(DateTime.now().subtract(_expiredIn));
        return isStale;
      },
    );
  }
}

With riverpod persist(), I can use destroyKey to force refresh, but I'd need to access the cached data from Riverpod to decide when to bump it, and that's not easily accessible.

Proposed solution:
A callback like shouldRefresh: (cachedData) async in StorageOptions would allow to check the state itself:

options: StorageOptions(
  shouldRefresh: (cachedData) async {
    final cache = ref.read(cacheManagerProvider);
    final time = await cache.readDateTime(cachedStaleKey);
    return cachedData.isEmpty || time?.isBefore(...) ?? true;
  },
),

Or Is there an existing pattern for this?

[rrousselGit]

The issue is that you're describing stale logic in code. So stale data isn't going to be destroyed if your provider isn't used.

I would subclass Storage and put that logic there, such that regardless of if the provider is used or not, stale data will be destroyed.

---

Anyway if you're looking for expiration dates, that's built directly inside persist/Storage. You can specify an expiracy date.

[pckimlong]

Thanks for the feedback, appreciate the pointer on subclassing Storage. Yes the built-in expiration covers the basics really well, but for more dynamic scenarios like checking timestamps, user prefs, server flags, etc., it'd be a nice enhancement to add optional provider-level control for conditional refreshes or destructions based on how the data was stored without the extra hassle.

Anyway, thanks again just hoping something like that might pop up down the line!

[TekExplorer]

Thanks for the feedback, appreciate the pointer on subclassing Storage. Yes the built-in expiration covers the basics really well, but for more dynamic scenarios like checking timestamps, user prefs, server flags, etc., it'd be a nice enhancement to add optional provider-level control for conditional refreshes or destructions based on how the data was stored without the extra hassle.

Anyway, thanks again just hoping something like that might pop up down the line!

you can always define custom keys that can receive the extra information, or have your storage be composable in such a way as to make that easy.