Provider Extensions

[onatcipli]

Is your feature request related to a problem? Please describe.
While working with providers in Flutter, I've observed that the current methods, though effective, can sometimes lead to boilerplate code. This repetition can hinder readability and maintainability, especially in larger projects.

Describe the solution you'd like
I've opened a pull request (#840) that introduces Provider Extensions to the Widget class. These extensions are designed to offer alternative syntactic sugar that reduces boilerplate, providing a more streamlined approach to handling providers. Here are the specifics:

ProviderExtension

  provideProvider: Acts as an equivalent for Provider.
  provideProviderValue: Acts as an equivalent for Provider.value.

MultiProviderExtension

  provideMultiProvider: Acts as an equivalent for MultiProvider.

ChangeNotifierProviderExtension

  provideChangeNotifierProvider: Acts as an equivalent for ChangeNotifierProvider.
  provideChangeNotifierProviderValue: Acts as an equivalent for ChangeNotifierProvider.value.

Example:

Traditionally, you would use:

Provider<MyObject>(
  create: (_) => MyObject(),
  child: MyWidget(),
);

With the proposed ProviderExtension, it can be written as:

MyWidget().provideProvider(
  create: (_) => MyObject(),
);

Describe alternatives you've considered
The existing methods for providing providers have been effective and are widely used.

The proposed extensions are not meant to replace them but to complement them, giving developers an additional choice in how they structure their code. Developers can continue using the traditional methods or opt for the proposed extensions based on their preference and the specific scenario.

Additional context
These extensions aim to simplify and enhance the developer experience when working with providers in Flutter. By reducing boilerplate, we can increase code readability and maintainability.

[rrousselGit]

I'm personally not fond of the idea.

This is not something Flutter generally does. And to begin with, providers are used inside MultiProvider nowadays. We rarely use a provider on its own.
It also creates more competing syntaxes for the same thing.

If using extensions for single-child widgets was a common practice, I wouldn't mind. But that's not the case.

At the same time, this is something which can easily be done on your own. It doesn't have to be inside Provider itself to be doable