Repository navigation
Add a "design discussion" section to the setState method #12296
Description
Activity
We used to just have a
markNeedsBuildmethod 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. We found people understand much more easily that if you didn't change any state, you don't need to call it; if you did change some state, you call it and change the state during the call.
Eventually we plan to make some lints verify that anything you use in your
buildfunction you only set fromsetState, to catch cases where people set things but don't notify the framework.Reacted by Mateus Felipe C. C. PintoReacted by Tomek Polański, Iiro Krankka, Tom Gilder and Pratap SinghI'll add a "Design discussion" section to the setState docs talking about this. Let me know if there's anything else you'd like covered in the docs for this, I'm happy to add more information there.
Maybe the better docs was needed for
markNeedsBuild? Or just rename it toonStateChanged()or whatever? Lambda instantiation is not free, it adds needless code nesting, it also increases cognitive code complexity and puzzles more experienced devs (me :D).Otherwise, thanks for the explanation! :)
Maybe the better docs was needed for markNeedsBuild?
Maybe, but in my experience we shouldn't depend on people reading API docs. :-)
Or just rename it to onStateChanged() or whatever?
That would be inconsistent with our naming guide: https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#naming-rules-for-typedefs-and-function-variables
Lambda instantiation is not free
It's a pretty small cost when called once per frame (which is what you generally expect for setState). Also, it's not called during performance-critical periods; it's called in response to user input generally and so we have more CPU to play with here than if it was during the frame itself. Also eventually I wouldn't be surprised if we were able to get the compiler to just inline this.
it adds needless code nesting
Needless is subjective here. I would argue the need is to show that this is the block that is actually mutating the state.
it also increases cognitive code complexity
Well as noted above, in practice it seems to have actually reduced it.
and puzzles more experienced devs (me :D).
Yup, that's why we need to add more to the documentation. :-)
- changed the title
[-]Why setState?[/-][+]Add a "design discussion" section to the setState method[/+]on Dec 20, 2017 Closing, as there are several places in our documentation nowadays that talk about
setState()and state management.Eventually we plan to make some lints verify that anything you use in your
buildfunction you only set fromsetState, to catch cases where people set things but don't notify the framework.@Hixie Is there any issue tracking this?
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.- locked as resolved and limited conversation to collaborators
on Aug 2, 2021 9 remaining items
- added a commit that references this issue
on Aug 10, 2023 This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.- locked as resolved and limited conversation to collaborators
on Aug 24, 2023
I just started playing with Flutter, and the most obvious stuff is
setState. Honestly, it does not look good. Why would you want to put all your mutations into a lambda, especially if they are all side-effecting? Wouldn't it be better just to callupdate()directly after you do all the state mutations?The pattern looks like it came from a functional architecture, but the main point is missing - state mutation should have been encapsulated inside
setStatefunction, but this is not the case for Flutter. Without immutability, pure lambda and state change encapsulation all of this doesn't seems have any meaning.