Riverpod code generation and autodispose

[kwill39]

Currently, providers that are created through code generation are set to be automatically destroyed when the state of a provider is no-longer used (i.e. - autodispose). However, providers which are created manually are not automatically destroyed. Instead, the developer must explicitly specify this as a desired behavior by using .autodispose. This creates a bit of confusion for developers who decide to use code generation for the first time after having routinely created their providers manually in the past. They expect the generated provider to have keepAlive = true by default, just as it would be if they created the provider manually (without explicitly specifying to use .autodispose).

Ultimately, it might be a good idea for us to try to stick to one convention, if we can. keepAlive is true by default for all providers or keepAlive is false by default for all providers, regardless of whether they're created manually or automatically.

Thoughts?

[rrousselGit]

This is a voluntary decision.

The goal is to have autoDispose on by default. In the future, defining providers manually will be deprecated/removed (once we have metaprogramming). At that point, we'll have only one scenario: autodispose on by default.

It is enabled by default because this is generally the better option when using Riverpod correctly.

[rrousselGit]

I didn't do the switch in the manually defined providers to enable it by default, because that would be a breaking change.

Ultimately, the important is documenting nicely this change in default behavior.

[akarabach]

It is enabled by default because this is generally the better option when using Riverpod correctly.

How to store global state then (between screens, auth state, etc)? For me keepAlive: true like a singleton which holds state forever as soon as it was created once.

[kwill39]

To me, it feels like you're eluding to the question—"What is the correct way to use Riverpod?", which I think is a fantastic question within the context of discussing autodispose.

Personally, I don't know the answer at this time. However, as for auth state changes, specifically, I think I might be able to shed some light on that. From what I understand, you're likely always going to have something watching that auth-state provider (ref.watch/listen) so that your UI can react whenever a user is logged out. So, it would never be automatically disposed.

[akarabach]

I would prefer to have ability to set autodispose (keepAlive) in future. Listen only for not to lose it - does not make sense for me, I agree that it saves resources, but having less requests to backend (firebase, lambda, etc) is more important (for example).

[kwill39]

I don't think keepAlive is being removed. In the future, keepAlive will be false by default.

From what I understand, you will still be able to set keepAlive = true in the future as well.

// with code generation
@Riverpod(keepAlive: true)