Home > Back-end >  Should state practically be at the root of the tree (in most cases) in Flutter?
Should state practically be at the root of the tree (in most cases) in Flutter?

Time:01-08

I'm utterly confused regarding the question of state management in Flutter.

So far I have read that the states of widgets have to be nested as deep in the tree as possible (or rather as close to the affected widget as possible) for better performance.

But what if such a nested state widget (InheritedWidget for example) has another state widget somewhere above it? Does the state widget at the lower level not loose it's state when the state widget higher in the tree requests rebuild for all of its descendants?

With this line of thought have I came to the conclusion, that state widgets just have to be at the root in the end, but I guess I'm wrong somehow.

CodePudding user response:

The first part of your question is correct - If a widget's state changes, this might require all its children to redraw.

But this is precisely why it is important to nest state as deep down in the widget tree as possible!

Assume the contrary, that all state information is stored at the root of the widget tree, at the very top. Now if any information changes, no matter how small, it will lead to a complete traversal of the widget tree, rebuilding everything in the worst case.

And aside from the tree traversal, your application will also become very memory intensive. If all state is stored at the root, flutter can never tell when it is okay to release some information from memory. If the user leaves some views and the views are dismissed from memory, the information for them will still be stored at the top. And the only way to check wether that information is still needed would be to once again check the whole tree - very expensive!

All of this can be mitigated by putting your state as close as possible to the widget that will consume it. Because then

  • If the state changes, only a small subtree of the whole widget tree has to be traversed - This is fast.
  • If a widget is dismissed, flutter can also release all of the state information that has been stored for it. This frees memory.

CodePudding user response:

yes ! every state widget has its own state and they are all independent. if the state of widget X is updated, only widget X will be updated

let suppose that you have an application that sows a family tree. in widget A you get the gradfather from an API, when you click on it you will be redirected to widget B where you can find his childrens, when you click on one of his childrens you go to widget C which shows the childrens of the selected father in widget B, now let's supposse that you want to add one children to this father. you call the add-children endpoint. the problem here is that widget A will not be updated.

one solution to this, and to understand the state tree logic, is to pass a functionthat updates widget A from widget A to widget B and pass it from widget B to widget C and call it when an update happens either on widget B or C or even on A so widget A gets updated and you got the updated family tree in widget A

CodePudding user response:

So basically flutter have it's own state management that is called setState(() {}) itu will update the state of the screen where setState is called if i have a button class widget in it's own file if i press the button i want to change the button name to something else so the setState will update the state or variables in the button class/widget.

Now how if the button wants to update a state/variables in the different class but in same screen? Since setState only update it's own class, so you to give the button onTap property with function constructer like this final Function onButtonTap; then put it on onTap like

onTap:() {
widget.onButtonTap();
}

    

Then in the screen where you want to update the state just call onButtonTap then use setState there

  • Related