I've noticed a difference between the auto-complete code from VS Code using Flutter and the code shown in the Riverpod documentation.
Auto-complete code in VS Code using Flutter. If I do this and choose to convert it to a StatefulWidget (from extends StatelessWidget):
StatelessWidget into StatefulWidget
class MyHomePage extends StatefulWidget {
const MyHomePage({super.key});
@override
State<MyHomePage> createState() => _MyHomePageState();
}
class _MyHomePageState extends State<MyHomePage> {
@override
Widget build(BuildContext context) {
return someWidgetHere();
}
}
Moreover, if I do this and choose to convert it to a ConsumerStatefulWidget (from extends ConsumerWidget):
auto-complete code suggestions
It will generate this code:
class MyHomePage extends ConsumerStatefulWidget {
const MyHomePage({super.key});
@override
ConsumerState<MyHomePage> createState() => _MyHomePageState();
}
class _MyHomePageState extends ConsumerState<MyHomePage> {
@override
Widget build(BuildContext context) {
return someWidgetHere();
}
}
However, from this Riverpod documentation, which I will quote:
As for ConsumerStatefulWidget, we would instead write:
class Home extends ConsumerStatefulWidget { const Home({super.key}); @override ConsumerState<ConsumerStatefulWidget> createState() => _HomeState(); } ...
You might also notice this line: ConsumerState<ConsumerStatefulWidget> createState() => _HomeState();
Note that these differences still work fine. What I'm asking is, does this mean the Riverpod documentation, with the given code snippet, incorrectly specifies the type parameter?
1 Answer 1
inheritance tree
does this mean the Riverpod documentation ... incorrectly specifies the type parameter?
No.
It describes classes in the most generic and broadly applicable terms possible, while the OP autocompletes are taking advantage of additional details to tailor the solution to your particular codebase. In each place where the class identifiers differ, you will see the autocompletion is narrowed down so it specifies a subclass of the one that appears in the documentation.
Feel free to adopt those wider parent / ancestor class names from the documentation in your own code, if desired.