The Interview That Left Me Shook
So there I was, sitting in a virtual meeting room, ready to impress these fine folks with my Flutter knowledge. Everything was going smoothly until the topic of Stateful vs. Stateless widgets came up.
Interviewer: "We never use StatefulWidgets. They should be banned. All state should be handled by a state management solution like Provider, Riverpod, or Bloc."
Me, in my head: "Did I mishear that? Maybe my internet lagged and he actually said ‘we mostly use state management’?"
But no, he doubled down, claiming that StatefulWidgets are bad practice and should never be used in production code. At that moment, I had two options:
- Politely agree and move on, ensuring my interview went smoothly.
- Go full-stack Flutter philosopher and educate them on why this was absolute nonsense.
I went with Option 1 because, let’s be honest, arguing in an interview is a terrible idea. But the frustration still lingers, so here I am, writing this blog post to restore balance to the Flutter universe.
Stateful vs. Stateless Widgets: What’s the Big Deal?
Let’s start with the basics.
- StatelessWidget: Immutable. Once built, it cannot change its internal state.
- StatefulWidget: Mutable. Can maintain state and update UI accordingly.
A StatelessWidget is great when your UI doesn’t need to change dynamically. Think of displaying static text, icons, or images. But what happens when you need a widget to react to user interaction? That’s where StatefulWidgets shine.
A simple example:
class CounterWidget extends StatefulWidget {
@override
_CounterWidgetState createState() => _CounterWidgetState();
}
class _CounterWidgetState extends State<CounterWidget> {
int _counter = 0;
void _incrementCounter() {
setState(() {
_counter++;
});
}
@override
Widget build(BuildContext context) {
return Column(
children: [
Text('Counter: $_counter'),
ElevatedButton(
onPressed: _incrementCounter,
child: Text('Increment'),
),
],
);
}
}
This is a simple counter app. If we made this a StatelessWidget, it wouldn’t work because _counter
needs to change.
"Just Use State Management" – A Misguided Statement
Now, let’s address the biggest myth: "We don’t need StatefulWidgets because we have state management."
State management solutions like Provider, Riverpod, and Bloc are amazing for app-wide state, but do we really need them for everything?
Imagine needing to track whether a button is pressed or a text field is focused. Are we supposed to create a Provider for that? Wrap everything in a ChangeNotifier? Dispatch Bloc events for every button press?
That’s like hiring a team of engineers to change a light bulb. Sure, it works, but why overcomplicate things?
When to Use StatefulWidgets
- UI elements that only need local state (e.g., toggles, animations, text field controllers)
- Keeping state within a widget that doesn't need to be shared
- Simple interactive components like an expandable card or a dropdown menu
When to Use State Management
- When state needs to be shared across multiple widgets (e.g., user authentication, themes, shopping cart data)
- When managing complex business logic
- When state persistence is required across screens
The "Necessary Evil" Argument
Yes, StatefulWidgets aren’t perfect. They have limitations, like lifecycle constraints and the potential for unnecessary rebuilds. But calling them evil is like saying knives are bad because they can cut people—when, in reality, they’re essential for cooking.
A well-balanced Flutter app should use both StatefulWidgets and state management wisely. Blindly banning StatefulWidgets is like saying, "We’ll only use screwdrivers from now on—no hammers allowed!"
So, to my dear interviewer, if you’re reading this: I respectfully disagree. And to my fellow Flutter devs, don’t let anyone tell you StatefulWidgets are obsolete. They’re a necessary tool in your toolkit, and knowing when to use them makes you a better developer.
Conclusion
To all the Flutter developers out there—next time someone tells you StatefulWidgets should never be used, take a deep breath, smile, and know that you’re dealing with an extremist. Keep coding, keep learning, and use the right tools for the right job!
And as for my interview? Well… let’s just say I won’t be working there anytime soon.
Top comments (1)
There are people who pretends to be intelligent though they only have superiority in term of corporate position. We should avoid such negativity and move on....