Feature request: ref.listen or select should support filtering null values

[MarkusKnochKenbun]

Feature request: ref.listen should support filtering null values

It's often the case for me that I use a AsyncNotifier and I need to run side effect in a listen and most of the time I combine it with selects, but they are always awkward to handle. I want to only fire the side effect when there is actually data present.

Currently the workaround is an early return null guard inside the callback:

ref.listen(
  myProvider.select((s) {
    final value = s.value;
    if (value == null) return null;
    return (foo: value.foo, bar: value.bar);
  }),
  (previous, next) {
    if (previous == null || next == null) return; // awkward
    // actual logic
  },
);

It would be nicer to have a way to express this more cleanly, for example a listenWhenData variant or a selectWhenData.

ref.listenWhenData(
  myProvider,
  (value) => (foo: value.foo, bar: value.bar),
  (previous, next) {
    // previous and next are guaranteed non-null here
  },
);

ref.listen(
  myProvider.selectWhenData((value) => (foo: value.foo, bar: value.bar)),
  (previous, next) {
    // previous and next are guaranteed non-null here
  },
);

Selecting on non async Providers is always so easy but for AsyncProviders it feels very unintuitive for now.

[rrousselGit]

I'm not opposed to some form of filter operator.
The question is: What would happen if you use it with watch?

Given:

ref.watch(provider.selectWhenData((value) => (foo: value.foo, bar: value.bar)),

What is returned when no value is there? Because that'd have to be supported too.

Chance are the value would be null ... meaning you'd still end-up with a null value in your listener.

[MarkusKnochKenbun]

Its completely fine for me that watch forces me to deal with the value, of cource I need to return widgets at the end of the day. But in a side effect callback its a different story.

To be honest dealing with AsyncValue in the ui also is very confusing when wanting to use select.

Currently I do it like this:

final userNameAsync = ref.watch(
      settingsProvider.select(
        (asyncValue) => asyncValue.whenData((data) => data.userName),
      ),
    );

While you actually would it expect to work like this:

// But that reurns a Future, which I dont want in ui code, only on a notifier.
final futureUserName = ref.watch(
      settingsProvider.selectAsync(
        (data) => data.userName,
      ),
    );

Maybe wanting select to work uniformly across watch and listen is needlessly perfectionist. Having better ways of dealing with nulls and AsyncValues with listen and watch would be great.

[rrousselGit]

Maybe wanting select to work uniformly across watch and listen is needlessly perfectionist.

watch is just a small wrapper around listen. They are the same thing. Splitting them would cause massive increase in complexity to the interface and implementation