beforeDispose or beforeInvalidate hook, happen before invalidate about riverpod HOT 5 OPEN

Could you be more specific? I don't really understand the problem, not what is suggested here.

Some examples of the problem and the suggestion would be great.

from riverpod.

@rrousselGit

final getProvider = FutureProvider<String>(
  (ref) async {
    // get remote data
    return '';
  }
);

//in other function somewhere esle
void updatedata()async{
  // await update data
  ref.invalidate(getProvider)
}

so in this case ref.invalidate(getProvider) will trigger get remote data right after the update. Sometime it doesn't leave enough time for server to update data all the way through. so it returns un updated data.
A hook could be something like this.

final getProvider = FutureProvider<String>(

  (ref) async {
    ref.beforeInvalidate(() async{
      await Future.delayed(const Duration(seconds: 1));
    })
    // get remote data
    return '';
  }
);

This could be useful in some other usecases I think

from riverpod.

I'm sceptical about this. If the provider was invalidated, to me it should rebuild immediately the next time it is used.
Adding an indirect delay like that would be confusing. It'd be hard to know why the refresh isn't happening.

To be, it sounds like you want to do:

//in other function somewhere esle
void updatedata()async{
  await Future.delayed(const Duration(seconds: 1));
  ref.invalidate(getProvider)
}

from riverpod.

In fact, the fact that you need this delay is weird to me.

Your server should be up-to-date. If it isn't, that means you didn't await something.

from riverpod.

yeah some time the request sent too fast and server still cache I think.

//in other function somewhere esle
void updatedata()async{
  await Future.delayed(const Duration(seconds: 1));
  ref.invalidate(getProvider)
}

This works most of the time. but Sometimes in the UI ref.invalidate(getProvider) scatters other places. so would a bit inconvenient to add a wait time to other places like that.

from riverpod.