Proposal for context.read & context.watch

[schultek]

Hi. I recognize I'm a bit late to the discussion after reading through #335, but anyways:

When I migrated my projects to riverpod 1.0.0, I was really unhappy about the missing context.read extension. It is just such a convenient method, and in my case having a large project with lots and lots of state, I found myself needing to refactor almost every StatelessWidget to a ConsumerWidget, and also many StatefulWidgets. I know there was already a long discussion. For me it's just that I would go and define a context.read extension in my projects anyways, so why keep it out of the package?

But:

One strong point I totally get is that we would want a similar interface on context that on ref, which means context.watch needs to happen first. Digging through the code, I also understand why it's not easy (any maybe not feasible) to implement this. But being the naive coder I am, I thought "Surely this must be doable somehow? It can't be impossible?".

So here I am coming up with a context.watch implementation:
https://gist.github.com/schultek/b9d3e10eaf6c62ee741baf49e813febb

It uses InheritedWidget (oh my) and dependOnInheritedElement with aspect: provider (yikes). Yes it's not really pretty and maybe uses anti-patterns. However it works! On any context, rebuilding only the right widgets. It supports any provider, as well as .autoDispose and .family.

So I guess my question is if you could see this coming back to riverpod in any way? Do you have feedback on the implementation? I could understand if this is not going to end up in the main package, due to its 'hackiness'. In that case I would probably publish it as a separate package (after some more testing of course). But I wanted to get your thoughts first.

[rrousselGit]

The problem is, aspects are never cleared unless a widget is unmounted.
This is an issue when a widget conditionally depends on a provider, such as with selectors or families

Say you do:

context.watch(family(variable))

then when the variable changes, the provider listened to changes – which means a new aspect. But the previous aspect will still be active.

So if variable changed from 42 to 21, then the widget will actually be listening to both 42 and 21.
And of course, if that provider was autoDispose, then the instance with 42 as a parameter wouldn't be disposed of.

Same goes for simple conditions, like:

Widget build(context) {
  if (condition) context.watch(foo);
}

When condition goes from true to false, the widget should properly stop listening to the provider, and the provider should properly get disposed if autoDispose.

[rrousselGit]

That's what ConsumerWidget is for. It tracks which providers were used within build, and properly stops listening to providers that are no longer used by build.
This required overriding the Element of the consumer widget, hence ConsumerWidget.

We'd have to update Flutter to properly clear aspects when no longer used by build. But that is not reasonably doable.
In particular, one problem is the existence of didChangeDependencies

Widgets are able to subscribe to an InheritedWidget inside didChangeDependencies, which is not always executed when build is. So a widget may listen to an InheritedWidget even when that widget's build method isn't.

It's highly unlikely that the Flutter team will change something here.

[schultek]

Got it. I feared there was still something I missed. Thanks for explaining. 👍

[schultek]

Just fyi, I've adressed the issues and published it as a new package 'riverpod_context'.

[131e55]

Thanks and Congratulations to stable v1.0.0🎉

When I want to read or write any provider (and don't want to rebuid), I have used context.read.
From v1, should I use Consumer(or ConsumerWidget) even I don't want to rebuild?

Before v1

class HogeWidget extends StatelessWidget {  
  @override
  Widget build(BuildContext context) {
      // No need to watch
      final changeNotifier = context.read(hogeChangeNotifierProvider)

From v1

class HogeWidget extends ConsumerWidget {  
  @override
  Widget build(BuildContext context, WidgetRef ref) {
      // No need to watch
      final changeNotifier = ref.read(hogeChangeNotifierProvider)

[rrousselGit]

As the doc mentions, it's anti-pattern to use read inside the build method like so. You should use ref.watch. So you'll need ConsumerWidget

[TimWhiting]

Yes, it will not trigger a rebuild unless you use ref.watch. So it is essentially a StatelessWidget if you only use ref.read. However, I would not assume that you don't need to watch something unless you are only using ref.read in an onPressed or other callback.

[131e55]

Thanks for reply! Solved it!
I missed the detailed doc😅
https://riverpod.dev/docs/concepts/reading/#dont-use-refread-inside-the-build-method