Flutter's setState() might not be what you think it is

Mar 29, 2021

Here’s a somewhat embarrassing assumption I made about setState when I started to learn Flutter almost 4 years ago.

We all know setState from the counter example:

class _MyWidgetState extends State<MyWidget> {
  int _counter = 0;

  void _incrementCounter() {
    setState(() {
      _counter = _counter + 1;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Text("The current value is $_counter!");
  }
}

Here’s how I thought it worked:

There’s one stateful field called _counter.
We also have a Text widget that displays the value of _counter.
Every time we want to update _counter, we also have to wrap it in an anonymous function and pass it to setState. Otherwise, the framework doesn’t know what was updated.

Four months into my Flutter journey, I found out that assumption number three was not true.

We do have to call setState when updating _counter, but there’s absolutely no need to do it in an anonymous callback.

This:

setState(() {
  _counter = _counter + 1;
});

is exactly the same as this:

_counter = _counter + 1;
setState(() {});

The Flutter framework does not magically inspect code inside the anonymous function and then do some diffing to see what changed.

Whenever you call setState, the widget rebuilds - even if nothing changed and the callback passed to setState was empty.

What I had initially assumed about setState was totally made up in my own head.

A peek behind the curtains

Let’s see how the code behind setState looks like:

@protected
void setState(VoidCallback fn) {
  assert(fn != null);
  assert(() {
    if (_debugLifecycleState == _StateLifecycle.defunct) {
      throw FlutterError.fromParts([/* ... */]);
    }
    if (_debugLifecycleState == _StateLifecycle.created && !mounted) {
      throw FlutterError.fromParts([/* ... */]);
    }
    return true;
  }());
  final dynamic result = fn() as dynamic;
  assert(() {
    if (result is Future) {
      throw FlutterError.fromParts([/* ... */]);
    }
    return true;
  }());
  _element.markNeedsBuild();
}

Let’s remove the assertions:

@protected
void setState(VoidCallback fn) {
  final dynamic result = fn() as dynamic;
  _element.markNeedsBuild();
}

We can actually boil it down even more:

@protected
void setState(VoidCallback fn) {
  fn();
  _element.markNeedsBuild();
}

All that setState does is calling the provided callback and then the associated element gets scheduled for a new build.

No magical field diffing here.

So why do we have setState then?

Because of UX studies ran by the Flutter team.

They do a lot of it.

Back in 2017 and 2018, there was a GitHub issue label called “first hour”. The Flutter team ran developer UX studies and observed how Flutter newcomers would use Flutter when left on their own for an hour. Those studies would shape future API decisions for Flutter.

Apparently, the setState thing is one of these findings.

From the GitHub issue that made me realize I had been living in a lie:

We used to just have a markNeedsBuild method but we found people called it like a good luck charm – any time they weren’t sure if they needed to call it, they’d call it.

We changed to a method that takes a (synchronously-invoked) callback, and suddenly people had much less trouble with it.

There’s also a StackOverflow answer from Collin Jackson from the Flutter team back then:

When Flutter had a “markNeedsBuild” function, developers ended up just sort of calling it at random times. When the syntax switched to setState((){ }), developers were much more likely to use the API correctly.

So the whole setState API is just a mental trick. And it seems to work - apparently it lead into people building their widgets less often.

I never had problems knowing when to call setState, but I can definitely see myself wondering “who’s Mark and what is he building?”

Mystery solved.

Conclusion

What does all of this mean?

Should we now convert all our setState calls to something like this?

_counter = _counter + 1;
setState(() {});

Probably not.

Even though there’s no difference, calling setState with an anonymous callback feels right.

At this point, the anonymous callback is an established convention and anything else just feels weird.

9 comments

likes

Randal L. Schwartz

March 29, 2021 at 09:10 PM

I believe we agree that the code inside the callback provides valuable documentation as to why the view update is needed by having updated some model data. Leaving it empty is now a code-smell to me… more of a voodoo stick shaking to hope those values change correctly without understanding the process fully.

Reply to Randal L. Schwartz

Iiro Krankka

March 29, 2021 at 10:01 PM

the code inside the callback provides valuable documentation as to why the view update is needed

I like that. It’s probably one of the main reasons why people found setState with an anonymous callback easier to comprehend!

Leaving it empty is now a code-smell to me

Yeah, that irks me out too.

There have been cases where I felt it was probably okay to leave it empty, but those are few and far between.

Reply to Iiro Krankka

Shawn

March 30, 2021 at 01:26 AM

Interesting, I always just viewed it as syntactic sugar, if I’m changing one thing I include it in the brackets on a single line, if I’m changing multiple values, then I just so setState((){}) as the last line in the method.

I don’t often find it to be ambigious why we are rebuilding, but I can appreciate the self-documenting aspect of it.

Reply to Shawn

Iiro Krankka

March 30, 2021 at 06:46 AM

if I’m changing multiple values, then I just so setState((){}) as the last line in the method

With multiple values, I still prefer doing this:

setState(() {
  // ...
  _value1 = "blah";
  _value2 = 123;
  _value3 = true;
});

Like Randall said, it feels more like a self-documenting piece of code that way ¯_(ツ)_/¯ An empty function inside setState also somehow looks like there’s something missing.

Different strokes for different folks.

Reply to Iiro Krankka

javad

April 14, 2021 at 06:20 AM

thank you I couldn’t understand this and i hated flutter because of it.

Reply to javad

Arvind

April 17, 2021 at 04:48 AM

Hey iiro, Yesterday i saw your flutter video of theater app with andrew brodan. Why don’t you start teaching us that how to create a modern web app as of 2021. Maybe you can create your own youtube channel and start teaching us.

Reply to Arvind

Max

June 03, 2021 at 05:46 PM

Hello, Iiro! I am happy to hear that you found what I did too. Sometimes, we, developers have our own needs, styling, or to make convenient things more convenient =) So, don’t use the setState() method directly in daily code. Just I made an extension on State and added a couple of handy methods: first I can call without an anonymous empty function. And also I check if the widget actually is mounted before calling setState. I don’t want to discuss is it right or not. Just my points: 1) one reason is when we can call setState(), the widget might be not mounted. So, at some point you get exceptions. And write everywhere “if (mounted) setState(() { … });” you probably will tire. 2) some methods have complex computation. It’s possible to have different if/else or switch statements. So, if you are sure, that when the method will be done, you have to rebuild your widget. It probably maybe a callback from any notifier. And you don’t want to wrap the callback function into setState. Maybe, again, at some moment of the callback function, you understand you don’t want to update the widget state. 3) One of the points is that to put complex computation into the setState method will make code not beautiful and pretty strange. Because, usually we see that in the setState method we have just fields with any modification operations, like a = newValueA; or _counter++. But what if we have a logic of those if/else, switch, etc. And to wrap all the stuff in the setStateCall within a new anonymous function often does not have sense.

4) I don’t know how to explain all the situations. But I do have more clean and readable code and without an explicit call of the setState method. For instance, when we use FutureBuilder, StreamBuilder, ValueListenableBuilder, … or use the convenient flutter_hooks library, we don’t need to call the setState method explicitly. And nobody has problems with the magic of why don’t we call setState call manually. 5) Also, when I use one strategy to code with my wrapper methods, I don’t want to break this coding approach by making a mix of different approaches.

But of course, we have to see code to understand why don’t all the developers need to put computation into setState() or why we have to call at the end the setState(() {}) within a new anonymous function instead of a call wrapper like updateState() extension method on State which also checks that widget is actually mounted.

Iiro, happy coding. Thank you for your discovering and investigation! See you!

Reply to Max

Dave

June 20, 2021 at 12:30 AM

Wow, I made exactly the same assumption. I actually much prefer putting the setState(() {}) being the last line of a method now.

This makes much more sense to my brain as it tells me that it’s just there to ask for a visual rebuild, not to indicate that the variables wouldn’t be updated without that wrapping call.

Thanks.

Reply to Dave

BelaMathur

September 26, 2021 at 02:33 PM

The anonymous function inside setState is actually a bad design but it since it is the norm now, it passes off for a great design.

Java developers who have used java.util.Observable will easily realize that setState is doing two things at once - setChanged(true) + notifyObservers().

There is absolutely no reason to make all modifications to the state in a function passed to setState or even invoke setState upon every modification. You need to invoke setState only if you want the changes to be reflected on the UI. For example, you can keep making changes and finally invoke setState.

Of course, in real life, you can’t do that because other people will not understand the logic and will just follow the _incrementCounter(setState() { _counter = _counter + 1; });

Reply to BelaMathur