The `WidgetRef.invalidate` method should not depend on `ProviderScope`

[BreX900]

The problem I am trying to solve is to be able to invalidate all providers used by a widget (on a screen) in order to have updated data when opening a screen.

For example:

final _provider = FutureProvider((ref) async {
  return 1;
});

class HomeScreen extends ConsumerStatefulWidget {
  const HomeScreen({super.key});

  @override
  ConsumerState<HomeScreen> createState() => _HomeScreenState();
}

class _HomeScreenState extends ConsumerState<HomeScreen> {
  @override
  void initState() {
    super.initState();

    // This line of code throws an exception
    // dependOnInheritedWidgetOfExactType<_UncontrolledProviderScope>() or dependOnInheritedElement() was called before _HomeScreenState.initState() completed.
    ref.invalidate(_provider);

    ref.listenManual(_provider, (prev, next) {
      print('$next');
    });
  }

  @override
  Widget build(BuildContext context) {
    final value = ref.watch(_provider);

    return Scaffold(body: Text('$value'));
  }
}

The solution could be that the WidgetRef.invalidate method does not depend on _UncontrolledProviderScope but only reads its value as for the WidgetRef.refresh method.

Then the WidgetRef code would become:

base class ConsumerStatefulElement extends StatefulElement
    implements WidgetRef {
  @override
  void invalidate(ProviderOrFamily provider, {bool asReload = false}) {
    _assertNotDisposed();
    ProviderScope.containerOf(this, listen: false).invalidate(provider, asReload: asReload);
  }
}

I also thought about using State.didChangeDependencies, but it would complicate the code quite a bit, and I would also have to move ref.listenManual or other code
Furthermore, it is not clear to me why I have to depend on ProviderScope in order to call WidgetRef.invalidate

[rrousselGit]

This could be doable. Although for starter, I'm quite skeptical about the idea.

Calling invalidate inside initState is a pretty bad idea.
Even if we remove the "can't depend on InheritedWidget in initState", you'll find other issues like "markneedsbuild() called during build"

[BreX900]

@rrousselGit I understand the problem, but it remains a valid use case to be able to open an app screen by forcing data invalidation in order to show only valid data.

Autodisposing a provider would not solve the problem, since I may have already loaded some data into a screen already present in the navigation stack.

I am invalidating many providers in initState by doing this and I am not getting any errors. Is this case probably already handled?

final ref = ProviderScope.containerOf(context, listen: false);
ref.invalidate(myProvider);

Thank you so much for your time

[rrousselGit]

@rrousselGit I understand the problem, but it remains a valid use case to be able to open an app screen by forcing data invalidation in order to show only valid data.

It is never going to be correct to call invalidate inside initState like that. That's breaking the restrictions around widgets. If you don't see errors, you're lucky.

You need to do the invalidation before the widget appears on screen.

[BreX900]

@rrousselGit This would mean that I would have to invalidate X providers every time I open a screen. This is really inconvenient, especially if I have a widget that is part of a screen and I want to invalidate its data when it is mounted.
I would have to remember that wherever I use that screen or widget, I would have to invalidate all the providers it uses. This solution is too prone to errors.

In my opinion, invalidate should only mark widgets as dirty/invalid and, in the next frame, clean up the ProviderContainer from those that are no longer used. If there is already a frame being rendered, it should do so in the next one.

I would like to achieve the same functionality as react-use-query, which invalidates the query when the useQuery hook is mounted

[rrousselGit]

Just do Future(() => ref.invalidate()) then.

Flutter and React have widly different expectations on the component lifecycles. React doesn't care too much about async, while Flutter is pretty strict about it.
Ultimately this is not a decision Riverpod made, but is one made by Flutter. Riverpod is just following it.

[BreX900]

Yes, I had considered this solution, but it is not ideal since I am going to ref.watch the provider on the build, which would trigger the provider to be built/created twice and an extra rendering/build cycle (if they had not already been created)

For now, all the solutions seem pretty bad to me. The last one you suggested is the most problematic, given that some screens are composed of different providers and therefore could launch several void http calls