Add a new parameter to define ourselves the provider name with @riverpod annotation

[julienlebren]

I am moving some StateProvider to the new @riverpod syntax but I have some naming problems.

Example:

I have the following enum:

enum AuthMethod {
  anonymous,
  email,
  google,
  apple,
}

My old provider:

final authMethodProvider = StateProvider<AuthMethod>((_) => null);

If I want my new provider to be named authMethodProvider, I need to write the following class:

@riverpod
class AuthMethod extends _$AuthMethod {
  @override
  AuthMethod? build() => null;

  void update(AuthMethod? method) => state = method;
}

But of course it causes a problem because the class has the same name as the enum. It means that an enum SomeName can't be read with a provider named someNameProvider. However, for code reading clarity, I can't imagine to name this provider differently...

I know we can set the suffix ("provider") through build.yaml but it does not cover my "issue". Could we imagine something like this (or a better way of you have a better idea), where we can be free to chose the full name of the provider that will be created?

@riverpod(name: "authMethodProvider")
class RandomName extends _$RandomName {
  ...
}

[babbage]

We also have encountered this same naming conundrum.

One approach that might? be simpler would be to special case a particular naming combination. For example, in the specific case where the class name ended with the string "Provider", Riverpod could just generate the name without appending a second "Provider" to it? That would enable the example above to have a class name AuthMethodProvider that provides a State of AuthMethod, autogenerating a provider called authMethodProvider.

A similar approach could be taken where the class and state are respectively named AuthMethodNotifier and AuthMethod generating an authMethodProvider (rather than authMethodNotifierProvider if that was preferred over using Provider as the magical keyword?)

[ymauray]

I'd be happy with any of the suggestions above !

[rolandtolnay]

This has been marked as "Post 3.0 release" 7 months ago. Considering its a fairly isolated change involving only the generator with no backwards side-effects, is there a more specific timeline for it? Are you accepting PR's if one would to open one?

[rrousselGit]

Feel free to make a PR if you're confident in doing it. Make sure to add tests and docs :)

[pirrest]

I set provider_name_suffix and provider_family_name_suffix in build.yaml to empty string. Generator stops adding "Provider" so I can add it myself to my class name.

https://pub.dev/documentation/riverpod_generator/latest/

[pirrest]

Sorry, it doesn't work. It works only for classes but not for global methods... There will be compilation errors from generated files :(

[TekExplorer]

I set provider_name_suffix and provider_family_name_suffix in build.yaml to empty string. Generator stops adding "Provider" so I can add it myself to my class name.

https://pub.dev/documentation/riverpod_generator/latest/

Family name suffix does need to be left normal, as it creates a Family class that needs to be distinct, I believe.