Request for comments: Should all providers be merged into one? about riverpod

[rrousselGit]

I'll go for StateNotifierProvider.autoDispose.family(...).
This avoids a name clash with variables named provider, and is more natural for people migrating from provider

It'll then be accompanied by:

• .retry, as per #42
• (maybe) .restorable, for state restoration:

  final model = StateNotifierProvider.future.restorable(
    (ref) async {
      final json = await ref.restore();
      final initialState = json == null ? null : MyModel.fromJson(json);
      return MyNotifier(initialState: initialState);
    },
    name: 'model',
    serialize: (state) => state.toJson(),
  );

[davidmartos96]

I agree with the proposal.
I think that having too many different class names can be confusing for people trying out the package.
I also agree that keeping some of the providers with the original name can be helpful for people used to the well known Providers in the provider package.

[rrousselGit]

I've just realised that we can't implement Provider.changeNotifier(...) as ChangeNotifier is Flutter-only, and extensions do not allow adding static members.

So this reinforces the idea of keeping StateNotifierProvider & co, and apply this logic only to AutoDispose, Family and a potential Retry.

[rrousselGit]

Another alternative is to do like @smiLLe suggested and go for final foo = provider.autoDispose(...) instead of final foo = Provider.autoDispose(...).

This will allow using extensions to add custom members. And to begin with, we don't care about const constructors, so this using a function over a constructor doesn't matter.

[rrousselGit]

Logging in implemented directly on ProviderScope

ProviderScope(
  observers: [
    LoggerObserver(),
  ],
  child: MyApp(),
);

class LoggerObserver extends ProviderStateOwnerObserver {
  ...
}

Although maybe we could have an "onChange" on providers individually

[rrousselGit]

I do. Finding Recoil made me rename Family. Originally the pattern was called "ParametrizedProvider", which just sounds bad

Anyway, we'll see later. I'll focus on retry/restorable. There's a bunch of work to do on for the provider code-generator

[smiLLe]

For my current project I started to do

final myProvider = createProvider.stateNotifier.family<T, Fam>((r, f) => .. );

by just using callable classes :)

[smiLLe]

Personally i would prefer Retry over anything else :P

[rrousselGit]

I like how composable the modifier idea is. It allows implementing commonly wanted features almost without doing anything.

Do you have any modifiers in mind that I haven't mentioned yet?

Currently we'd have:

• retry
• autoDispose
• family
• restorable

What other big feature would we want? 🤔

[davidmartos96]

@rrousselGit Some kind of logging mechanism? Not sure if that is possible, just sharing the idea 😅

[smiLLe]

What other big feature would we want? 🤔

Do you know recoil js? It is very similar to riverpod :) Maybe we can take some inspiration from them.
But right now, all i am missing is Retry and i like the idea of .restorable

[AlexHartford]

I would agree that the change in name convention makes a great deal of sense here.