I'm having confusion regarding the correct implementation of MVVM architecture in a flutter.
Does MVVM require separating just the UI calls from the UI or
separating the complete logic of the widgets, even if it is to update
a CheckBox?
If using setState does not raise performance issues, should we use it when following MVVM architecture?
If it is okay to have some logic inside of widgets, to what extent
should we do that?
Yes obviously , I suggest you to study Clean Architecture, Basically concept is that, You have to create ViewModel for every screen.
Screen will contain all the Widgets (View)
View Model will contain all functionality and variable which will be hold value which used in Screen (View)
It is perfectly okay for the widget to manage its state internally. It wouldn't make sense e.g. ListView not to manage its scrolling state. The same obviously applies to custom widgets.
See Differentiate between ephemeral state and app state for more information.
Related
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.
In Flutter does avoiding setState() achieve anything?
I have a StatefulWidget (screen) where I use Widgets that handle their own state completely with the exception of the FAB button. The Fab button is disabled or enabled when data has changed in order to allow the update of the DB when data has changed. I posted a question on SO as to how to use Provider to handle that and thus prevent the need to setState(), and implemented that with Provider.
When looking at another screen to implement something similar, I wondered if another solution may be better. This screen also contains Widgets that all handle their own state - TextFields with TextEditControllers, so the only place I was calling setState() was to enable or disable the FAB. I had previously created a Stateful Widget to create a CheckBox with its own state because the standard CheckBox doesn't have state. It's fairly simple and only 50 lines of code. So, I did the same with the FAB, I created a Stateful Widget (CustomFab) that encapsulates a FAB. When it needs to be enabled or disabled, it is called to set its own state, and returns a FAB that is either enabled or disabled with the appropriate color. Because I have other similar screens, I can use that same component with them.
Does it achieve anything by avoiding setState() in this situation (for mobile and Web), and if so, which is the best way to handle that (Custom-Widget or Provider or another)?
setState is merely avoided in Flutter development for two main reasons:
It rebuilds the whole widget, which may hinder performance on consecutive calls if not used correctly.
using setState only as a state management couples the business logic to the UI, which may reduce code re-usability and maintainability.
In simple apps, there are no significant issues in using setState. However, if you need more control over your code, I suggest going for more complex state management patterns.
I'm trying to figure out a way to implement the "expandable" behaviour illustrated in https://material.io/design/components/chips.html#input-chips.
I've dismissed using a combination of Stack+Positioned & AnimatedSwitcher, since this would require inserting the input chip at the scaffold's top level, when it's initial position should rather be determined exclusively by it's actual parent (e.g. a wrapping row). Everything else seems to contradict flutter's "overflow is evil" rule, however.
Any ideas?
I was unaware of the Overlay widget's existence and have built my implementation based on that.
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.