Is setState() heavy?

[Jaxon Du]

Let say top of my app hierachy is a stateful widget which has many child widgets. When a setState() is called, the build() method of the widget will be called, which means all the many child widgets will be re-created. Isn't this expensive operation?

How about creating new MaterialApp() or new Scaffold() widgets inside a StreamBuilder? Is it something we should avoid?

[Dale King]

Certain song by the Hollies comes to mind with the title ;-). (It ain't heavy, it's my brother)

That way can be heavy and is not recommended for serious apps. Much has been written about alternative patterns for this like Redux and BLoC and a search on those terms with flutter should provide you with a cornucopia of information. I will point you to a few videos that talk about these:

• https://www.youtube.com/watch?v=zKXz3pUkw9A by the creator of flutter_redux
  
• https://www.youtube.com/watch?v=RS36gBEp8OI this one use BLoC
  
• https://www.youtube.com/watch?v=HLop7s2sJ7Q This one implements the same functionality using each of the current technologies
  

[Ian Hickson]

setState itself is more or less free, but it schedules the current widget to be rebuilt, which will rebuild any widgets that are created by that widget.

Rebuilding the MaterialApp is probably pretty cheap, compared to what you might imagine.

Dale had some good pointers though. Generally I would recommend putting your app state outside of the widget tree, and then creating custom stateful widgets that are very localized and just update the parts that need updating, when the app state changes.

--
You received this message because you are subscribed to the Google Groups "Flutter Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flutter-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--
Ian Hickson

😸

[Gregg Reynolds]

Can somebody from the flutter team weigh in? I was under the impression the the Build machinery was highly optimized, such that nothing gets rebuilt unless it needs it (i.e. dirty) .

Gregg

[Ian Hickson]

setState is the mechanism by which widgets are marked dirty, so once you call setState, it is assumed that it needs it. If you return a different widget from your `build` method, then that widget is also assumed to be dirty, since it is not the same widget as before.

One way you can make builds more efficient is by making sure to return the same widget from your build method. We use this a lot, for example, that's why `const` widgets are more efficient (they're always the same instance). It's also why AnimatedBuilder takes a `child` argument and a `builder` argument, and then passes the `child` to the builder: the builder can then make sure to always use the same child instance in its output each frame, thus limiting the parts that are dirtied (and rebuilt) to the parts that changed (the parts created by the builder itself).

HTH.

(I'm from the Flutter team.)