• Declarative and Reactive Programming. • Handles a significant portion of your app's logic. • Built-in Error Handling and Caching. • Automatic Re-fetching
that provides lint rules to help you write better code, and provide custom refactoring options. • The package should already be installed if you followed the previous steps, but a separate step is necessary to enable it. To enable riverpod_lint, you need add an analysis_options.yaml placed next to your pubspec.yaml and include the following:
• The name of the annotated function determines how the provider will be interacted with. For a given function myFunction, a generated myFunctionProvider variable will be generated. • Must specify a "ref" as first parameter. Creating the provider (Functional Provider)
is equivalent to the place where you would normally put your logic in a non-notifier provider. • When a @riverpod annotation is placed on a class, that class is called a "Notifier". The class must extend _$NotifierName, where NotifierName is class name. • Notifiers are responsible for exposing ways to modify the state of the provider. • Public methods on this class are accessible to consumers using ref.read(yourProvider.notifier).yourMethod(). Defining a Notifier (Class Provider)
with the added benefit of offering us a "ref". • This enables our UI to read providers. • Widgets can listen to as many providers as they want. To do so, simply add more ref.watch calls. Consumer
rebuild whenever the provider’s state changes. ref.listen(): Go-to for reacting to state changes with side effects, such as showing a SnackBar or logging. ref.read(): Typically used for accessing a provider’s current state without listening to it. Whenever possible, prefer using ref.watch over ref.listen or ref.read to implement a feature. This way, the application becomes reactive and declarative. But it is recommended to use ref.read when logic is performed in event handlers such as "onPressed". + + + How to read provider state?