1. Section Intro
Notes
This section will cover Riverpod as a solution for dependency injection and reading asynchronous data in our widgets.
In other words, this section is about understanding how data flows from the repositories and into our widgets, and how Riverpod helps us connect everything together, while also giving us APIs for disposing things properly.
Note about vanilla Riverpod vs Riverpod Generator
When Riverpod was first introduced, it was using this kind of syntax for declaring a provider:
// provider that returns a string value final helloWorldProvider = Provider<String>((ref) { return 'Hello world'; });
But as of Riverpod 2.0, a new Riverpod Generator package was also added, making it possible to declare providers like this:
// provider that returns a string value @riverpod String helloWorld(HelloWorldRef ref) { return 'Hello world'; }
This approach relies on code generation, and you can choose to use it if you want.
I believe it's valuable to know both the "old" and "new" syntax, and as far as this course goes:
- from now until the end of section 12, we will use the "old" syntax (without code generation).
- in section 13, we'll upgrade the course project to use the new Riverpod Generator APIs.
Note about Riverpod Lint
In addition to Riverpod Generator, a new Riverpod Lint was also introduced.
This adds many useful lints and refactoring options that make it easier to write code correctly:
I may update the course to use Riverpod Lint in the future. But for now, you can get a good overview here:
Resources
- Riverpod.dev | Official documentation
- Flutter Riverpod 2.0: The Ultimate Guide
- How to Auto-Generate your Providers with Flutter Riverpod Generator
4 comments