[RFC] Fixing Riverpod's redundant "isLoading" gap when combining providers

[rrousselGit]

This is a follow-up to #4008
It details more the ref.setData part, to determine if this is valuable or we'd rather stick to the usual return data.

The problem

One of Riverpod's big issue when combining providers has always been:
Chaining asynchronous providers makes providers down the chain update 1+ frame after its dependency has updated.

Consider:

final valueProvider = FutureProvider<int>(...);

final doubleValue = FutureProvider<int>((ref) async {
  final value = await ref.watch(valueProvider.future);
  return value * 2;
}

...
ref.listen(doubleValue, (a, b) => print('${DateTime.now()} $b'));

In this example, updating value will print:

[00:00:00] AsyncLoading<int>()
[00:00:02] AsyncData(value: <new value>)

The reason for this AsyncLoading is twofold:

• When doing return value in an async function, Riverpod doesn't get access to the value until one frame has passed.
• Doing await ref.watch(valueProvider.future) adds another delay of one frame ; even if the value is already accessible.

As such, our doubleValue updates in a different frame than valueProvider. This is problematic if you were to render both in the same page, as an attentive eye would see one value change before the other.

Say you had your UI do:

Text('value: ${ref.watch(valueProvider).value}');
Text('value * 2: ${ref.watch(doubleValue).value}');

Then your UI may show:

// Initial render:
value: 1
value * 2: 2

// We update value
value: 5
value * 2: 2
// For a small amount of time, value and doubleValue are out of sync

// Last frame:
value: 5
value * 2: 10
// After a little bit, the values re-synchronize

It isn't horrifying, and it's very hard to notice. But it is a problem.

Proposal

To fix this issue, we'd have to change how FutureProvider emits its value and how we await other providers.

Removing the gap caused by return

Instead of return value * 2, we could do:

final doubleValue = FutureProvider<int>((ref) async {
  final value = await ref.watch(valueProvider.future);
  ref.state = AsyncData(value * 2);
}

This technically removes the delay introduced by return in async functions.
The problem is, it's easy to forget to call ref.state=.

Nothing forces you to ever set a state. If you forget to do so, your UI will permanently show a progress indicator. This sucks.
To fix this, we could instead do:

final doubleValue = FutureProvider<int>((ref) async {
  final value = await ref.watch(valueProvider.future);
  ref.returns(value * 2);
}

The idea is:

• FutureProvider would no-longer care about the return value. Instead we'd only react to ref.state changes.
• As such, FutureProvider's callback wouldn't be expected to return a Future<int> anymore, but rather a Future<Event>
• You would have no way to create an Event instance. As such, the only way to have the program compile would be to:
  • call ref.setData/setError and return the result
  • call ref.returns
  • throw
• ref.returns is sugar for ref.state = AsyncData(); and returns Never ; which aborts the execution of the function.
• We can also offer a ref.emit(stream) to fuse StreamProvider/FutureProvider while we're at it.

This likely sounds confusing. The idea is:
In practice, the compiler will force you to specify one return. It is a compilation error to not specify a return thanks to the fact that we need to return an Event.

As such, this isn't legal:

final doubleValue = FutureProvider<int>((ref) async {
  ref.setData(42);
  // Compilation error, no return
}

But this is:

final doubleValue = FutureProvider<int>((ref) async {
  ref.returns(42);
}

And this is too:

final doubleValue = FutureProvider<int>((ref) async {
  Event event;
   // Simulate some complex initialization logic:
  if (something) event = ref.setData(42);
  return event;
}

So all forms of initialization should be covered :)

Solving await ref.watch(provider.future)

For this, the solution is fairly simple: Use SynchronousFuture from Flutter
When a provider watches another provider and the value is already available, we'd be returning a SynchronousFuture.
This enables Dart to skip the await

The drawback is that this is a breaking change. The main reason is because SynchronousFuture only really works with await.

For example, you can't do:

Future.wait([
  ref.watch(provider.future)
])

Future.wait doesn't understand SynchronousFuture and will break.

Of course, we could consider offering two options: A ref.watch(provider.future) which returns a normal future. And a ref.watch(provider.syncFuture) (name to be determined),
Or we could have a lint rule which enforces await ref.watch(provider.future) and warn if you use the Future in other contexts.

Conclusion

What's described here is a bit of an advanced Dart topic, so it may be difficult to grasp.
But the idea is that with a small syntax tweak, we could remofe that pesky delay when combining providers.

The question that remains is:

• Is the gain worth the complexity?
  Folks are used to return value in their providers.
• Should synchronous providers use the same syntax, for consistency?

  final provider = Provider((ref) => ref.returns(42));

[lucavenir]

It's way less confusing that it first looked.
The comptime guarantees make me feel safe.
The gains are way too important as well.
So, yes, totally worth it.

Also, the confusing part to me is just the naming. And as you say it's very minor and it can change. Personally, I'd use ref.data, ref.loading, ref.error and ref.emit.

And yes, I'd prefer consistency. If folks have to learn a new syntax, be it, but let's have only one.
For sync providers it would be required to return ref.data, and that's it.

[snapsl]

The reason for this AsyncLoading is twofold:

When doing return value in an async function, Riverpod doesn't get access to the value until one frame has passed.
Doing await ref.watch(valueProvider.future) adds another delay of one frame ; even if the value is already accessible.

Interesting..
Is this a problem with the dart or riverpod scheduler? Other packages allow you to create computed values as well. Do they have the same problem?

[rrousselGit]

It's a Dart issue. I've made numerous language requests over the years to improve the current state of things.
Other packages have the same issue, or found a workaround similar to what's being described here.

The very fact that SynchronousFuture exists in Flutter proves that it's a broad problem.

[snapsl]

Thanks for clarification @rrousselGit. Adding an option to skip the AsyncLoading state is nice, even though most people (like me) will probably never notice the issue.

More concerning is the fact that this is actually a flutter problem.

[dorklein]

For consistency, I would go with

ref.setData(42)

(or whatever you decide to call it) for both sync and async providers. Let's keep them as similar as possible to avoid more confusion.

[snapsl]

I would prefer to return the actual data.
There is probably a way to check / flag internally if provider is already initialized and skip the AsyncLoading state on recompute.

[rrousselGit]

No we can't.
The point is that when using return data, the provider isn't initialized, and a delay is necessary. Otherwise Riverpod would already not show an AsyncLoading.

If you do this today, there's no asyncLoading:

final provider = FutureProvider((ref) async {
  ref.state = AsyncData(42);
  ...
})

The initial state isAsyncdata(42).

The issue is the return keyword itself.

[rrousselGit]

(updated the issue to use ref.returns(data). This removes the return keyword and makes slightly more sense syntactically)

[snapsl]

So this is about the fact that we can't update computed providers in the same frame due to scheduling of flutter and not about having the a redundant AsyncState? Because tracking if a provider was already initialized within a providerscope should be feasible.

[josh-burton]

I think the compromise is fine and well worth it to fix this issue, but I'm confused as to why this example doesn't need to return ref.returns?

final doubleValue = FutureProvider<int>((ref) async {
  ref.returns(42);
}