I am designing an application that uses setState to refresh a screen with all its widgets, however I would like to know if there is a way to exclude a particular widget (conainer) and all its children, as if I were treating it as a new page.
I tried to use Navigator.push (context, MaterialPageRoute), but it didn't work, I would like to treat the widget as a separate page. I appreciate any help
Short answer: You can't.
Long answer: You can change where the setState is called, create a separate StatefulWidget that contains only the ones that need to be rebuilded. However in most of the cases this is not possible because of the order you need to show your widgets or many other factors. That's when State Managements tools come in handy. You should try to learn how to use Provider, Riverpod or BLoC (which i personally recommend). If you want something a litte bit easier you can start learning how to use InheritedWidget starting in the documentation right here.
use const if possible. if not,
use StatefulBuilder , if you call setState inside this widget, the outside widget is not touched. Maybe it will suit what you need
Related
Maybe I don't understand the purpose of BloC or Provider but I'm confused as to why we would ever want to use them instead of using Flutter's built-in state management using the Stateful widget. I've just finished an app and can't remember a point where I wished I needed something more than the defaults. Can anyone clear things up for me?
There are a few reasons to use a BloC or Provider rather than Flutter's built-in setState:
BloC and Provider offer a more robust way to manage state.
BloC and Provider make it easier to update state across multiple widgets.
BloC and Provider can be used to manage async data.
BloC and Provider offer a more modular way to structure your code.
There are some case that you need BLoC to make you easier to define each state or condition that happening inside the application.
We will start discussing creating app like https://www.tokopedia.com/ (inspect element and go with phone size preview). You will see that between widget section tokopedia_ss there are some loading animations, and when the data load complete the widget loading animation changed to viewable widget (as user).
in bloc, you will make stateLoading(), stateComplete(data), stateFailed(data). and in the controller or screen you can describe what will happen when bloc state is stateLoading etc...
Creating this case with setstate is more complicated and make your code messy, also setstate will make phone render all the Build() code. not like BloC builder, you can define each widget or section.
So, when there are 10 sections, using Bloc you able to make it render each state but when using standard setstate it will render all the 10 sections in one time every state changes.
More information about BloC: article_about_BloC
I don't have any code to show just a question which makes me keep thinking of a better approach, every time I need to load data before rendering it to the image. I use initState or didChangeDependencies methods for that, but to keep that I've to make the whole widget stateful to access these methods.
So my question is there a better approach for Stateless Widgets not to be converted to Stateful and still get the same results are same.
I tried finding some results but couldn't, sorry if the issue already exists!
Thanks!
You can use state-management approaches flutter had provided like Provider, Bloc, Riverpod and many others. Choose one of them and you can manage the state of the widget using stateless widget.
I'm newly learning and creating simple app using flutter.
I created drawer inside Scaffold for some pages and I got confused if when I click the ListTiles, should it be routing the pages or just switch the body widget using setState().
I guess setState() must perform better but I'm not sure if this is a good practice for pages. If it does not have a big difference in performance, I would like to use routing the pages since it will be uniformed.
Personal opinion:
Avoid separating widgets into functions, use StatelessWidget instead. Cause every render function will rebuild whatever parameter changes.
Avoid using setState as much as possible, especially for large Widgets, instead use provider, get or simply use ValueNotifier if you dont want library. Cause setState will mark all things to be rerender include widgets that not need to be rerender.
Do not render too many things at once, if possible only render the views that are / are about to be displayed. Example using ListView.builder instead of ListView, ... etc
With image, please resize to suit your needs, a 2000x2000 image loaded as a 24x24 icon is clearly not a good idea.
using const.
I'd suggest to redirect user to the next page as it won't require a StatefulWidget (you can use navigator to navigate user to another activity) which will be lighter to run, as if you use IndexedStack or dynamically assign the widget it'll require the StatefulWidget..
As the below diagram shows Stateful widget covers what Stateless widget do, When I can do the same thing with Stateful widget, why Flutter designers added another widget? For increasing performance?
Please do not post the difference just answer the Why?
Would you always use a sword to do a knife's job? Given that you always have both of them available with easy access. The knife can't do everything a sword can, but would that mean that a sword should be used by default for everything, since it's more robust?
You'll have many widgets where the state of the elements will not change, and others where you will not have to use setState to update your UI either(given that you would rather not use higher level state management solutions).
Using stateless widgets as long as they can do the job, means more performent widget trees.
Please do not post the difference just answer the Why?
Knowing the difference between them is key to understanding 'why', and the differences are not just in the name less vs full. But sensing that you aren't interested, that's why.
Good Flutter code seperates the code into many small Widgets. In addition to better performance creating a StatefulWidget means that you have to write more code and add unnecessary complexity to your code.
For better performance. Stateless widgets are usually only called in one of these three situations:
1- widget is inserted in the tree.
2- Widget's parent changes its configuration
3- Inherited Widget it depends on changes.
Is it possible to do inter widget communication via something like a notification/event bus?
I need to be able to tell one widget to react to something that happened in another and didn't want to create a hard link.
The notification listener will only fire is if it is higher in the widget tree than both of the widgets so that isn't probably a viable solution.
There are lots of ways to do this depending on your use case.
You could have them be AnimatedWidgets that are passed a ValueNotifier or ChangeNotifier as the listenable. You can see this pattern in the Gallery's animation example.
You could use StreamBuilder to have your widgets rebuild automatically when new events come in on a Stream. There aren't a lot of examples of this in the main Flutter repo, but it's something that you're likely to need once you start using plugins or doing network I/O.
You could use a GlobalKey to get currentState and have one State call methods on the other. This is how snackbars work (example).
You can also extend InheritedWidget to provide widgets with information that wasn't passed as a constructor argument, and they'll automatically be marked for rebuild when that information changes. This is how Themes work, for example.
If you can provide more details on what your widgets do / what their relationship is, or ideally a code snippet I can help you decide which approach would make the most sense for your situation.