'autoDispose' forces itself upon all providers combining with an autoDispose provider?

[wujek-srujek]

I have a timerNotifierProvider which is autoDispose, and I want to use it in another provider (see #564 for the use case and more code). My first attempt was this:

final timerStatusProvider =
    Provider.family<TimerStatus, Duration>(
  (ref, interval) => ref.watch(timerNotifierProvider(interval)).status,
);

This fails to compile with:

The argument type 'AutoDisposeStateNotifierProvider<TimerNotifier, TimerState>' can't be assigned to the parameter type 'AlwaysAliveProviderBase<Object?, dynamic>'.

After some time I tried adding the .autoDispose modifier and then it worked. Some observations:

1. The documentation is not clear about it at all, as far as I can tell. Maybe it would be a good idea to mention it somewhere?
2. This means that autoDisposed providers can only ever be used from other autoDispose ones, essentially forcing autoDispose on any provider wanting to combine it. On the conceptual level, why is this the case?

[rrousselGit]

There is an explanation in the doc:

https://riverpod.dev/docs/concepts/modifiers/auto_dispose#the-argument-type-autodisposeprovider-cant-be-assigned-to-the-parameter-type-alwaysaliveproviderbase

[wujek-srujek]

Right, thanks, I don't know how I could have missed it.

May I ask why? If the user wants to use an 'autoDisposable' provider A from an 'always alive' provider B, its their choice, and A wouldn't be disposed of as long as B is alive, which is Ok I think, and the semantics of autoDipsosable is still complied with - there is one listener (B). If the user want B to be autoDisposable as well, they can do it, but maybe they don't want this (for whatever reason) - now they have to do it.

Is this to prevent bugs, or is there a technical reason for it? I'm just curious if something is made impossible to implement by forcing all providers to be 'autoDisposable' down the chain.

[rrousselGit]

its their choice, and A wouldn't be disposed of as long as B is alive

As in A watches B like so?

final b = Provider.autoDispose(...);
final a = Provider((ref) => ref.watch(b));

That is not what happen. The logic is reversed: B wouldn't be disposed as long as A is alive. And considering A is always alive, B is never disposed.

Considering B is marked with "autoDispose" there is a clear inconsistency. So Riverpod makes this a compilation error because this is most definitely a bug.

[wujek-srujek]

This is what I mean, you wrote the same thing but inverted the providers, in my example it was:

final a = Provider.autoDispose(...); // auto disposed
final b = Provider((ref) => ref.watch(a)); // always alive

in which case a would never be disposed automatically because the b 'always alive' provider never dies and listens to a, i.e. keeping a alive forever. Right?

But what's wrong with this? The user will always be able to add 'autoDispose' to b if they want this behavior (as they are forced to do right now anyway).

I personally don't see any inconsistency here. E.g. similar things with various dependency injections framework exist (like Spring in Java world):

• They support singletons (instanced created once for the whole lifespan of the app) and 'prototype's (a new instance created each time for each injection point, also possibly having their own 'dispose' methods when they are killed).
• If a 'singleton' type B wants an instance of a prototype type A injected, it can do it, without forcing the programmer to make B type a prototype as well. Instead, it just works, and it is effectively downgrading the prototype A to a singleton (which is implicit), and maybe this is exactly what the user wants (and yes, this is actually very common). But yes, it might also be a source of bugs.

In the case of Riverpod, provider b ('singleton' in the analogy from above) would be downgrading a ('prototype' from above) from being autoDisposed to always alive, which might be necessary for some use cases. The point is, I don't know if it will ever be necessary, but it is now impossible as the library actively prevents it.

I'm just voicing my fear of making some things impossible / very hard to implement because of the need to add 'autoDisposed'. I simply don't believe in forcing users to do something they might not want for the sake of 'fixing bugs' for them, is all. Like e.g. provider (the previous package) BuildContextX.read checking if it was invoked in build and failing with an exception if true, which was once implemented and then reverted because it turned out there were valid use cases for such code. If use cases of b not being autoDisposed although it uses a which itself is autoDisposed appear in the future once more and more users adopt Riverpod, it might be hard to make it possible due to the code written now.

[wujek-srujek]

But anyways, my original question has been answered.

[rrousselGit]

which was once implemented and then reverted because it turned out there were valid use cases for such code. I

No, there are no valid use-case for calling read inside build, be it with Riverpod or Provider.
I simply decided to remove all asserts because it is too mentally stressful to have to answer every issue about it.

And I do plan on making a linter for those.

But what's wrong with this? The user will always be able to add 'autoDispose' to b if they want this behavior (as they are forced to do right now anyway).

You can still do it with:

final b = Provider.autoDispose((ref) {
  ref.maintainState = true;
  ref.watch(a);
});

The compilation error is important. 99% of the time this is a mistake, and this mistake is really difficult to debug, especially on larger graph.

For example a variant of the issue would be:

final a = Provider.autoDispose()
final b = Provider.autoDispose((ref) => ref.watch(a));
final c = Provider((ref) => ref.watch(a));

A user may think "Why isn't b getting disposed? All of its dependencies have autoDispose too"

When this compilation error didn't exist, numerous people complained about a lot of time lost in debugging.