Skip to content

Latest commit

 

History

History
30 lines (20 loc) · 2.1 KB

.story.md

File metadata and controls

30 lines (20 loc) · 2.1 KB
focus
lib/presentation/manager/bindings/counter_view_binding.dart:17

MVI & Clean Code: Rendering Logic of State in Flutter : Riverpod story : The ViewModel has arisen

"our providers become bloated god classes with state and business logic thrown all over the place." Somewhere in Reddit

The problem and why we complicate things.

We need to understand that the provider is a very simple and easy to explain state management tool, especially for newbies, but I just don't understand how using such singletons in application development can lead to a clean architecture. Not to mention not being able to use any of the methods in my providers without jumping through hoops. It makes no sense for me to build clean architecture or die trying. If you have one provider per page (or area) like ViewModel, then it can't really become a big god class. It should only contain the models of this page and some methods. This way, you can easily call notifyListerns, whenever you do something with your models, instead of calling it from inside the model. In addition to this, you can have service classes that have nothing to do with the provider and only contain logic.

Dig deeply into ViewModel

In all places of the widget, we call methods from ViewModel e.g. this one is called when the big fab button is pressed In subwidgets we call direcly counters EvenCounter and Counter in Even State and in Odd state Counter

And yes, you can see that the order of the widgets changes when the state changes. At the same time, so as not to kill the clock , we added the logic for switching states to our view model.

And after all this code looks simple and easy to understand