overrideWith and Notifiers: Migrating from StateNotifierProvider to NotifierProvider

[jakeaaron]

I'm currently in the process of upgrading from Riverpod 1 to 2. I want to know how to subclass Notifiers and be able to override the notifier's provider with different subclasses of different variants (family vs non-family, for instance).

In my current implementation, we have a handful of cases where we create a StateNotifier implementation T that provides a state S with additional methods to handle user interaction. There are cases where we subclass T (ST) and provide new constructor parameters and override methods or add additional functionality. Then, any widgets expecting T can be wrapped in a ProviderScope where we can override the provider of T with a new provider of ST. We can use overrideWithValue or overrideWithProvider where the provider types can be different as long as they both return a T and S (for instance, the base class provider can be non-family and a subclass can be a family).

I have not figured out how to gain the same functionality with Notifier, since it seems the Notifier class is tightly coupled to the provider providing it.

For example, how could I do something like this with Riverpod 2s Notifier class?

final baseProvider = NotifierProvider(BaseNotifierClass.new);

final subclassProvider = NotifierProvider.family(FamilyNotifierClass.new);

class WidgetThatExpectsBaseClass extends ConsumerWidget {
        Widget build(BuildContext context, WidgetRef ref) {
       return Button(
           child: Text(ref.watch(baseProvider.select((value) => value.text))),
           onPressed: ref.watch(baseProvider.notifier).onPressed,
       );
   }
}

class ParentWithOverrideWidget extends ConsumerWidget {
    return ProviderScope(
       overrides: [
            baseProvider.overrideWith(() => ref.watch(subclassProvider.notifier))
       ]
       child: WidgetThatExpectsBaseClass(),
   );
}

This doesn't work for a few reasons:

1. FamilyNotifierClass can't subclass BaseNotifierClass because the build methods are different
2. I can't just use a mixin to share functionality because the mixin doesn't meet the NotifierT constraint of a NotifierProvider providing the base class, which means I can't have the subclass just use the mixin to share logic
3. I suppose I could try just using a generic Provider instead of NotifierProvider to provide the base mixin instead of the Notifier, but, I don't even know if that would work. It seems like it would break expectations around the NotifierProvider and Notifier.

[snapsl]

I don't know riverpod 1.0 but there is a migration guide to the new api.
I think you are looking for something like

final exampleProvider = Provider<BaseNotifierClass>((ref) => throw UnimplementedError(''));

which would remove the family provider.

You can then instantiate different subclasses with a ProviderScope

 return ProviderScope(
       overrides: [
            baseProvider.overrideWithValue(SubClass())
       ]
       child: WidgetThatExpectsBaseClass(),
   );

This is also shown by the todo example.

[jakeaaron]

Yes, That's what I mentioned as my 3rd point, but I'm not sure if providing a Notifier using Provider instead of NotifierProvider is expected? Considering the riverpod generator would generate a NotifierProvider.

[rrousselGit]

It's not clear to me what you used to do with StateNotifier, so I'm not sure how to help.

[jakeaaron]

For instance, one StateNotifier was a base class for all of our MediaPlayer state and methods. We have many different implementations, depending on what kind of media it is and where the data comes from. One implementation may take in different ids as parameters to load the media metadata. Then, we have shared media widgets that only need to expect the base class type to interact with play/pause, etc.

It kind of feels like NotifierProvider's are not meant to be overridden. Is that true? Or, do you have any recommendations for this pattern?

[AnonymousDev190]

I have a similar but more simple issue 3664.