Talent Apps

The nature of the use case is that A is not interested in this provider. A classic example is a master/details scenario: - Screen A presents a list of items...

The provider will be initalized with the item that was selected in the list. Then the app will navigate to screen B where you can edit the properties of the...

Code example: ``` void onItemSelected(BuildContext context, WidgetRef ref, Item selectedItem) { ref.read(editedItemProvider.notifier).setItem(selectedItem); Navigator.of(context).pushNamed(screenB); } ``` ``` class Item { final String name; const Item(this.name); Item copyWith(String? name) => Item(name ??...

With the current implementation, `editedItemProvider` will be disposed before screen B is launched, even though screen B watches this provider.

It would work, but relying on a specific timeout is more error prone, while relying on adding/removing a listener is exact. With a timeout you also hold the provider state...

Cool. An automatic disposal after at least one listener would help addressing issues like that.

Indeed this scenario is very common.

@rrousselGit this feels a bit awkward since you listen to something that you are not interested it. One more thing, the fact that this feature doesn't solve ALL scenarios is...

@rrousselGit As for your example: - If the provider is never listened to, it will remain alive, that's the expected behaviour I guess. - If it's possible to restrict this...

@rrousselGit The entire point of this feature is separation of concerns. Creating an ad-hoc listenter where it is not needed seems a bit weird.