RFC: Do Families need the abillity to be overridden?

[rrousselGit]

Context

With the death of macros, I've been investigating how to improve Riverpod's syntax without relying on code-generation.

The goals are:

• Reducing the number of providers (ideally just 1)
• Supporting any form of function for family.

Specifically, this issue is triggered by the second bit.

One motivation behind code-generation was to support a broad scope of provider parameters, including named parameters, optional ones, and even default values.. Lately, we even got generic support, and can write:

@riverpod
Future<T> generic<T>(Ref ref, {String search = ''}) => ...;

I've been investigating how to achieve the same without code-generation. I have various ideas in mind, but they have one flaw:

We loose the ability to override an entire Family :

ProviderScope(
  overrides: [
    genericProvider.overrideWith((ref, arg) => ...)
  ]
)

At least, we can't do it in a type-safe way.

But we can still override one provider:

ProviderScope(
  overrides: [
    genericProvider<int>(search: 'John').overrideWith((ref) => ...)
  ]
)

Now comes the main topic:

Is loosing the ability to override an entire family in a type-safe way a blocker?

My assumptions are that:

• overriding an entire family is primarily used by tests
• tests could get away with overriding one provider instead of the whole family.

Possibly workaround: A non-typed test-only way to override entire families.

Given my assumption that family.overrideWith is mostly test-specific, it's less important that the API is fully type-safe (because a test will fail if there's an issue)

With that in mind, we could offer a function which looks like:

@visibleForTesting
Override overrideWith(
  Object? Function(Ref ref, Object? arg) cb,
)

The idea is that such function would not be typed.

• The return value may not match what the provider expects (in which case we'll get a cast error in the test)
• The argument will be typed as Object?, and you'll need to cast it if your stub relies on arguments to work

Of course, code-generation would still be fully typed (and wouldn't be test-only).

Alternatively: Just remove family.overrideWith and keep it a code-gen-only feature

If the unsoundness of the proposed workaround is a no-go, we could just remove the API entirely.
Folks could migrate their tests by overriding one provider at a time instead of the whole block. That might be more tedious sometimes, but there's not much else we could do.

Or just don't change the family syntax if we can't have overrideWith

This is the worse-case-scenario. We'd keep the current syntax for the sole sake of overrideWith.

This feels incorrect, as I doubt many people override entire an family often ; especially in production code.

---

So, in summary, here are a few questions for you:

• Do you use the ability to override entire families in your apps?
• Do you do so only inside tests?
• If you do, would you mind migrating from provider.overrideWith((ref, arg) => ...) to provider(<value>).overrideWith((ref) => ...) ?
• Would you care if provider.overrideWith((ref, arg) => ) was test-only and wasn't type-safe?
• If you use provider.overrideWIth((ref, arg) =>...) in production code, what's the use-case?

[romaingyh]

I never used this override in tests or production. With examples given, I personally think that overrideWith(value) is a good deal if it allows riverpod to go forward and remove codegen / unify providers.

[RepliedSage11]

We lose the ability to override an entire Family :

Can we do that now?😳 The only time I actually needed to override a whole family I wasn't able to do so since a family provider does not have an overrideWith method. Am I missing something?

I have this in one of my tests:

final container = createContainer(
  overrides: [
    encryptionStrategyProvider(
      encrypt: true,
     ).overrideWith(NoEncryptionStrategy.new),
  ],
);

If I change it to

encryptionStrategyProvider.overrideWith(NoEncryptionStrategy.new),

I get a The method 'overrideWith' isn't defined for the type 'EncryptionStrategyFamily'.

[rrousselGit]

You can do:

final provider = Provider.family((ref, arg) => 0);

provider.overrideWith((ref, arg) => 0);

Although it looks like code-gen 2.0 didn't get this feature somehow. Looks like I forgot? If you don't use codegen, it's a thing.
And the 3.0 branch does have this feature for codegen too.

[RepliedSage11]

I only use codegen so that must be it. Answering your questions:

Do you use the ability to override entire families in your apps?

No, since it is not a thing for codegen yet. Would be a yes if I could (but definitely not something I can't live without).

Would you care if provider.overrideWith((ref, arg) => ) was test-only and wasn't type-safe?

I can see how this can be used for initialising async APIs. So not sure if it should be test-only?

If you use provider.overrideWIth((ref, arg) =>...) in production code, what's the use-case?

I thought about a potential case in one of my apps. Think "demo-mode" where you can use an app with some predefined data without hitting the actual backend. I haven't implemented that yet but I was thinking about using provider overrides for something like that. This can still be done without family overrides but I think it would just be more verbose and error prone.

I think I would want to have something like this always return the same mock data no matter the params passed to the provider.

@riverpod
Future<List<Wallet>> walletList(
  Ref ref, {
  CurrencyType? currencyType,
  String? currency,
}) async {
  final walletData = await ref
      .watch(accountServiceProvider)
      .getWalletsData(currencyType: currencyType, currency: currency);

  return walletData.wallets;
}

Then again I didn't even know you can override families until today so I would have looked for a workaround anyway.

[rrousselGit]

So not sure if it should be test-only?

No way I'm adding an API that's not type-safe in production code.
Riverpod is meant to be safe.

Tests are for dev only, so that's fine.

Think "demo-mode" where you can use an app with

If the main for your demo app is in test/main.dart, that should be fine. I'd just rather not offer an unsafe API that folks can ship with a --release build without ignoring some warnings along the way.

[benthillerkus]

Being able to override an entire family is useful for tests; typesafety wouldn't be important though.

[snapsl]

I am also mainly focused on using Riverpod with codegen.
However, simplifying the non-codegen API would be a significant improvement.

With the death of macros, I've been investigating how to improve Riverpod's syntax without relying on code-generation.

The goals are:

• Reducing the number of providers (ideally just 1)
• Supporting any form of function for family.

Does this mean we would have a single familyprovider for everything?
Maybe a little concept / sneak peak showing this api would be beneficial.

[rrousselGit]

Does this mean we would have a single familyprovider for everything?
Maybe a little concept / sneak peak showing this api would be beneficial.

There are multiple competing solutions and nothing is set in stone. I'd rather not trigger debates over the new syntax now.
I'll show it separately once I'm at a more advanced stage,

But yes the goal is to unity stuff.

[dorklein]

I only use overrideWith in tests and I wouldn't mind to change it to single value genericProvider<int>(search: 'John').overrideWith((ref) => ...).

I think this feature shouldn't stop the progress of Riverpod.

[MattK97]

I only use overrideWith in tests and I wouldn't mind to change it to single value genericProvider<int>(search: 'John').overrideWith((ref) => ...).

I think this feature shouldn't stop the progress of Riverpod.

Same at my end. Generally if this helps us with shipping simpler production code then we should go this way. The tests code shouldn't stop us here, we can adapt our tests 🙂 I wonder how often people uses it in their app's code 🧐