I am using the core classes (including extending StatefulWidget) in my first production app _before_ adopting a framework, so that I can fully understand how the underlying pieces all fit together. I think it's a matter of preference whether a Flutter developer picks the path of composing the low-level built in widgets, vs. adopting a higher-level framework like Bloc, Provider or Riverpod. My personal joy came from learning how StateBuilder and Streams worked, as I was building on top of StatefulWidgets. Some people learn more bottom-up, others top-down, others experiential or sideways, so maybe there's no one _right_ way to learn and build, just our individual ways. But I agree that StatefulWidget's API is very low-level, so any production use will have to build on top of it, except for trivial things (like "expand this" buttons).
Except for text controllers / other controllers, custom widgets you make, when you need a simple callback not tied to bloc so you can reuse it, when your passing copies of bloc as a parameter so you don't have app wide scope of the bloc...
I have seen people exactly with the same problem. They were studying their employees to use blocs as a state without stateful widgets, even including text controllers, scaffold keys and etc...
People not really understand StatefulWidget widget. StatefulWidget have more important things as set state. To change state you use ValueNotifier or any other state management. StatefulWidget used to check widgets life circle as on dispose, init state and the rest. All important elements in the Flutter is based on the StatefulWidget.
StatefulWidgets are just fine when you need ephemeral state for a widget that has a lifetime coincident with the widget and survives between builds. Yes, for any state that is shared beyond this scope or lifetime, you'll reach for a state management solution (my preference is Riverpod). But it seems like you're throwing the baby out with the bathwater in this video. The proper stance is a bit more tolerance.
The video shouldn't be called like that. StatefullWidget might be bad in your scenarios, but when you want to create reusable component that has state (i.e SingleChoiceWidget), StatefulWidget is the perfect choice, cause it can be reused anywhere.
I am using the core classes (including extending StatefulWidget) in my first production app _before_ adopting a framework, so that I can fully understand how the underlying pieces all fit together. I think it's a matter of preference whether a Flutter developer picks the path of composing the low-level built in widgets, vs. adopting a higher-level framework like Bloc, Provider or Riverpod. My personal joy came from learning how StateBuilder and Streams worked, as I was building on top of StatefulWidgets. Some people learn more bottom-up, others top-down, others experiential or sideways, so maybe there's no one _right_ way to learn and build, just our individual ways. But I agree that StatefulWidget's API is very low-level, so any production use will have to build on top of it, except for trivial things (like "expand this" buttons).
Now I completely agree with you. 😀 You summarized it in very simple and understandable way. Bottom line: avoid to use them as much as possible. 😉
Except for text controllers / other controllers, custom widgets you make, when you need a simple callback not tied to bloc so you can reuse it, when your passing copies of bloc as a parameter so you don't have app wide scope of the bloc...
I have seen people exactly with the same problem. They were studying their employees to use blocs as a state without stateful widgets, even including text controllers, scaffold keys and etc...
People not really understand StatefulWidget widget. StatefulWidget have more important things as set state. To change state you use ValueNotifier or any other state management. StatefulWidget used to check widgets life circle as on dispose, init state and the rest. All important elements in the Flutter is based on the StatefulWidget.
I actually said that in the video 😊
StatefulWidgets are just fine when you need ephemeral state for a widget that has a lifetime coincident with the widget and survives between builds. Yes, for any state that is shared beyond this scope or lifetime, you'll reach for a state management solution (my preference is Riverpod). But it seems like you're throwing the baby out with the bathwater in this video. The proper stance is a bit more tolerance.
Just a note: Your current thumbnail says "StatelessWidget sucks" but this video is about StatefulWidget
OMG :O
The video shouldn't be called like that. StatefullWidget might be bad in your scenarios, but when you want to create reusable component that has state (i.e SingleChoiceWidget), StatefulWidget is the perfect choice, cause it can be reused anywhere.
It would be interesting to watch about navigation tools)
Like go_router?
@@codruterdei Yep, there are more options.