My understanding of state management is that calling setState()
alone opens up a variety of messy issues, code files become huge and difficult to debug, and it prevents holding a sensible structure to a project. In cases where the widget's appearance changes slightly, it makes little sense to have a complex architecture like BLoC or ScopedModel just to show/hide a widget (for example). However, the way I have understood it is that you can't mix setState()
and an architecture together, otherwise what's the point of the architecture?
Let's use BLoC for this question (simply because I happen to be using it), specifically this package. Let's say I have this super simple example code:
class MyWidget extends StatefulWidget {
@override
void createState() {
return _MyWidgetState();
}
}
class _MyWidgetState extends State<MyWidget>() {
bool _isShowing = false;
MyBloc bloc;
@override
void initState() {
super.init();
bloc = MyBloc();
}
@override
Widget build(BuildContext context) {
return BlocBuilder(
bloc: bloc,
builder: (context, state) {
return Column(
children: <Widget>[
Text(state.myText),
if (_isShowing)
Text("Button has been pressed!"),
RaisedButton(
child: Text("Show label"),
onTap: () => setState(() => _isShowing = true),
),
RaisedButton(
child: Text("Run event"),
onTap: () => bloc.add(NewEvent()),
),
],
);
},
);
}
}
In the crude example above, is it right/acceptable to mix the BLoC pattern with setState()
? Why would I not use BLoC to handle showing the Text
widget? Where do I draw the line? What are the pros/cons? Is there a performance difference?
Note: I'm not looking for "just merge the two Text
widgets together" answers. I'm looking for purely architectural perspectives.