Lifting state up and state: • State Management! Flut... In this video, I'm addressing why I think using StatefulWidget is not adequate for production applications or for any big Flutter project.
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.
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...
Most of the flutter related debates seem to have already taken place in the reactJs community I suppose. Using state in component may not be a useful as states need to be lifted and hence Redux, etc. Have seen similar vids where all the debates seem like deja vu :) Maybe someone has to do a vid of the similarity between React and Flutter, from a comcepts point of view (even build() is similar to render() ).
