When we want a StatefulWidget to rebuild we call setState()
but does it really matter if the code we type is inside that function or outside of it?
Is this:
class _ShoppingListState extends State<ShoppingList> {
Set<Product> _shoppingCart = new Set<Product>();
void _handleCartChanged(Product product, bool inCart) {
setState(() {
if (inCart)
_shoppingCart.add(product);
else
_shoppingCart.remove(product);
});
}
}
the same as this:
class _ShoppingListState extends State<ShoppingList> {
Set<Product> _shoppingCart = new Set<Product>();
void _handleCartChanged(Product product, bool inCart) {
if (inCart)
_shoppingCart.add(product);
else
_shoppingCart.remove(product);
});
setState((){});
}
}
You should do all your mutations inside the closure, and the computing outside of the closure.
Why ? Because setState
is potentially not called immediately. So in the meantime if something else force the refresh of your widget, you can have an undefined behavior.
This is usually not a problem. But it's safer to follow this rule.
According to the docs:
@protected
void setState (
VoidCallback fn
)
Notify the framework that the internal state of this object has
changed.
Whenever you change the internal state of a State object, make the
change in a function that you pass to setState:
setState(() { _myState = newValue });
The provided callback is immediately called synchronously. It must not
return a future (the callback cannot be async), since then it would be
unclear when the state was actually being set.
And also
Generally it is recommended that the setState method only be used to
wrap the actual changes to the state, not any computation that might
be associated with the change.
It's doesn't explicitly say any thing about if it's different to call is in or outside the function. But it does recommend to put it inside. And in my opinion it's also more readable and logical if you put the changes in side the setState
function