I think the main problem is the learning curve for each different "solution". It would have been much better if Flutter had a simpler/nicer state management system built-in, similar to SwiftUI's (the @state variables etc), which can limit their scope to pages, or whole app state (and they even have "data" state variables that automatically get saved/restored from disk by the system).
One thing I would add is exposing values from the View Model as a ValueListenable getter instead of directly using the ValueNotifier. This adds some more biolerplate but ensures all changes of the state can only happen in the View Model. Great video as always! 👍
Yup, I always do that as well, but it doesn't "ensures all changes of the state can only happen in the View Model" because if someone really wants it can be casted back to ValueNotifier :)
I started using flutter from the initial beta version and the concept of InheritedWidgets and ChangeNotifiers which was proposed in the flutter docs was very difficult as beginner to understand. Now after 7 years of creating apps with all the mentioned "state management" solutions, I came to the same conclusion. Flutter as a framework has a very good state management solution by it self. Make a video about go_router, which I belive is the go to for navigation in Flutter. Great video. I will buy your course for support!!
Would of course mean a ton if you get the course for support, but will try to add more things in the end so that even you can find some small nuggets in there! Related to navigation the main ones imo are go_router and auto_route. I am still kind of conflicted on navigation in Flutter so will see when a video comes out with that haha
I love MVVM, especially when using the stacked package. It's basically a convenience wrapper around ChangeNotifier, so it has not a lot of opinion in there, but reduces the amount of boilerplate code you need to build something. Also, it's super easy testible as all the code you want to test is detached from UI.
İ was using change notifier and provider to get them, but i cannot found decent way to access one to another, I started riverpod then. For example getting auth notifier variable from to another changenotifier model, how can I do this?
Not sure what I will do for youtube but I will sometime in the future have a open-source repo and the course will also go more in-depth on it soon as well!
It’s great to see your videos again! However, a Counter page is too simple an example to effectively demonstrate how this would scale. Part 2 video coming soon?
Alright good, I noticed that u excluded Streams from this solution. Does that mean it will be very complex for it? I use river pod and with stream notifier it’s very fun to work with. I can listen to my steam anywhere in the app.
Usually streams can be a foot-gun in many scenarios but it's also a valid approach and built-in. I have nothing against it, I just think there is better approaches to 95% of the scenarios.
Riverpod does caching, this is the main reason why it is useful. Most of the state management packages are unnecessary replacements for something that already exists (what you mentioned in the video: change/value notifier, listenablebuilder etc.) and are mainly just a way to promote the creator :)
In my opinion you should not intertwine caching and state management. Just take react as an example: React-Query is awesome for caching, but nobody would like to have that baked into a state management solution like Redux.
Aren't most of the state management solutions we have today all about having a class for the logic (Cubit, Bloc, ChangeNotifier, etc.) and widgets to consume the state changes coming from these classes? (BlocBuilder, ConsumerWidget, etc.) What would the problem these solutions have but won't be in the solution you are suggesting in the video if It's basically the same exact pattern? I'll only lose the features these packages offer more, only to find myself rewriting them myself and reinventing the wheel. So I would rather have a team of contributors maintain and develop it for me, and don't forget I'll be able to customize the packages as they fit me anytime.
I did try to cover that in the video of the potential downsides of using packages vs not. People are free to use whatever approach they want. If you prefer using bloc, blocbuilder, bloc in tests etc you are free to do so or if that is riverpod or any other package. I just personally found that the overhead of those packages end up being a net negative, rather than using the primitives already in the sdk that we have had for years (this has been true in teams as well as people end up trying to utilize the packages differently, in my experience). Teams are free to choose whatever approach they see fit to make an application. But I might also note that a lot of people end up relying on those packages so hard that they forget what they actually do, which is not hard to do yourself (or difficult) and will scale, really really well.
@@RobertBrunhage It will mostly take the same effort to switch from the packages, or your solution to a new solution since both are following a similar pattern. When it comes to updating the packages it still didn't make sense to me because I'm not forced to update and I'll mostly do it only when I can afford to and updating is a good idea in general so I can get the improvements and new features. And when it comes to small projects, it's also a great idea to use them from the start so that I can scale the project better later.
i still believe those state management packages pros are way better, some are even recommended by google, also the the approach almost always stays the same like bloc it's always event, and states
It's not even advice, it's Robert's approach as the title clearly states. But mvvm is clean architecture, they are not mutually exclusive 😅 And the feature based folder structure can still be used with mvvm architecture. It's rather bold calling something bad advice while not knowing what you're talking about.
@@aymanbarghout9106 I can accept it's his opinion, but still he is sharing it, so regardless of the validity of the information, he is still sharing it. Second, mvvm is not clean architecture for flutter development. That would be as if you told me mvc (model-view-controller) is clean architecture, hello 1973, please take C back.. and honestly, saying "you don't understand" is very weak argument. He is not not even telling them to use Bloc (even though 99.9% of industry is using it), it's just not a good look when you still have this "wHaT sTaTe MaNaGeMenT yOu ShOuLd UsE".. I am telling you honestly, some kids will look at this, and try to follow this advice.. there are industry standards for a REASON, and he should at least respect that to mention that.. this is not a mainstream advice which he is giving, and beginners should know that. And to repeat again,, MVVM is NOT a clean architecture in flutter development. If you don't believe me, go speak with cloude 3.5.
fully agreed, Clean architecture kind of old and even some famous framework likr laravel didnt do it. plus MVVM cannot be compared to Clean Architecture i think. you can do both@@aymanbarghout9106
Simply not true. The official flutter channel has feature stacked (which is MVVM) recently. Also, you can do feature based architecture with MVVM and even clean architecture with service locators. It's quite obvious to do it if you think about it.
100% agree. I have always use ValueNotifier, view model, and Service Locator.
I think the main problem is the learning curve for each different "solution". It would have been much better if Flutter had a simpler/nicer state management system built-in, similar to SwiftUI's (the @state variables etc), which can limit their scope to pages, or whole app state (and they even have "data" state variables that automatically get saved/restored from disk by the system).
Hard agree. The lack of recommendations are nice in some aspects and in other aspects, not so much
One thing I would add is exposing values from the View Model as a ValueListenable getter instead of directly using the ValueNotifier. This adds some more biolerplate but ensures all changes of the state can only happen in the View Model.
Great video as always! 👍
Yup, I always do that as well, but it doesn't "ensures all changes of the state can only happen in the View Model" because if someone really wants it can be casted back to ValueNotifier :)
After one year of silence, what a surprise! just watched an older video about records in Dart3 today.
Sweet, maybe I shouldn't take a 1 year break again haha
@@RobertBrunhage Well, you could, but I would prefer some new content too.
I started using flutter from the initial beta version and the concept of InheritedWidgets and ChangeNotifiers which was proposed in the flutter docs was very difficult as beginner to understand. Now after 7 years of creating apps with all the mentioned "state management" solutions, I came to the same conclusion. Flutter as a framework has a very good state management solution by it self. Make a video about go_router, which I belive is the go to for navigation in Flutter.
Great video. I will buy your course for support!!
Would of course mean a ton if you get the course for support, but will try to add more things in the end so that even you can find some small nuggets in there!
Related to navigation the main ones imo are go_router and auto_route. I am still kind of conflicted on navigation in Flutter so will see when a video comes out with that haha
I love MVVM, especially when using the stacked package. It's basically a convenience wrapper around ChangeNotifier, so it has not a lot of opinion in there, but reduces the amount of boilerplate code you need to build something. Also, it's super easy testible as all the code you want to test is detached from UI.
Really I'm always using Stacked for every app. I love how manageable and readable my code becomes without doing or adding too much of a boilerplate.
It’s good to see your videos again🎉
İ was using change notifier and provider to get them, but i cannot found decent way to access one to another, I started riverpod then. For example getting auth notifier variable from to another changenotifier model, how can I do this?
Welcome back!
I use either Bloc or MVVM + Signals. Not a fan of other solutions such as Riverpod.
Welcome back to RUclips ❤❤❤
Can you do a bigger project tutorial with this approach so we will learn from it? 💯💯💯
Not sure what I will do for youtube but I will sometime in the future have a open-source repo and the course will also go more in-depth on it soon as well!
@@RobertBrunhage Awesome!! 🚀
He's backkkk!!
It’s great to see your videos again! However, a Counter page is too simple an example to effectively demonstrate how this would scale.
Part 2 video coming soon?
Yes this is why I use stacked .. very clean and understable!!
Exactly! I love stacked for being simple and without a lot of dependencies. Just reducing boilerplate.
glad I'm not the only one using this approach)
Alright good, I noticed that u excluded Streams from this solution. Does that mean it will be very complex for it? I use river pod and with stream notifier it’s very fun to work with. I can listen to my steam anywhere in the app.
Usually streams can be a foot-gun in many scenarios but it's also a valid approach and built-in.
I have nothing against it, I just think there is better approaches to 95% of the scenarios.
With CLEAN Architecture I could imagine how a sample project would look like 😯👌🏼 thx
Since 2019 im still using set state im doing good
chad
Riverpod does caching, this is the main reason why it is useful. Most of the state management packages are unnecessary replacements for something that already exists (what you mentioned in the video: change/value notifier, listenablebuilder etc.) and are mainly just a way to promote the creator :)
In my opinion you should not intertwine caching and state management. Just take react as an example: React-Query is awesome for caching, but nobody would like to have that baked into a state management solution like Redux.
Aren't most of the state management solutions we have today all about having a class for the logic (Cubit, Bloc, ChangeNotifier, etc.) and widgets to consume the state changes coming from these classes? (BlocBuilder, ConsumerWidget, etc.)
What would the problem these solutions have but won't be in the solution you are suggesting in the video if It's basically the same exact pattern? I'll only lose the features these packages offer more, only to find myself rewriting them myself and reinventing the wheel.
So I would rather have a team of contributors maintain and develop it for me, and don't forget I'll be able to customize the packages as they fit me anytime.
I did try to cover that in the video of the potential downsides of using packages vs not.
People are free to use whatever approach they want. If you prefer using bloc, blocbuilder, bloc in tests etc you are free to do so or if that is riverpod or any other package.
I just personally found that the overhead of those packages end up being a net negative, rather than using the primitives already in the sdk that we have had for years (this has been true in teams as well as people end up trying to utilize the packages differently, in my experience).
Teams are free to choose whatever approach they see fit to make an application. But I might also note that a lot of people end up relying on those packages so hard that they forget what they actually do, which is not hard to do yourself (or difficult) and will scale, really really well.
go with bloc and don't listen to these people they are just milking the youtube algorithm for views
@@RobertBrunhage It will mostly take the same effort to switch from the packages, or your solution to a new solution since both are following a similar pattern.
When it comes to updating the packages it still didn't make sense to me because I'm not forced to update and I'll mostly do it only when I can afford to and updating is a good idea in general so I can get the improvements and new features.
And when it comes to small projects, it's also a great idea to use them from the start so that I can scale the project better later.
Part 2 video coming soon?
So no more Riverpod necessary?? Or could it still be useful?
You are free to use whatever you want.
I just found personally that it's usually a higher burden on the codebase than it needs to be.
@@RobertBrunhage I am intrigued. I should give it a try in a typical to-do-app.
this is exactly how i do it.
i still believe those state management packages pros are way better, some are even recommended by google, also the the approach almost always stays the same like bloc it's always event, and states
This is bad advice, don't do this. No one in the flutter industry is even bothering with mvvm. Use clean architecture - feature based approach.
It's not even advice, it's Robert's approach as the title clearly states.
But mvvm is clean architecture, they are not mutually exclusive 😅
And the feature based folder structure can still be used with mvvm architecture.
It's rather bold calling something bad advice while not knowing what you're talking about.
@@aymanbarghout9106 I can accept it's his opinion, but still he is sharing it, so regardless of the validity of the information, he is still sharing it. Second, mvvm is not clean architecture for flutter development. That would be as if you told me mvc (model-view-controller) is clean architecture, hello 1973, please take C back.. and honestly, saying "you don't understand" is very weak argument. He is not not even telling them to use Bloc (even though 99.9% of industry is using it), it's just not a good look when you still have this "wHaT sTaTe MaNaGeMenT yOu ShOuLd UsE".. I am telling you honestly, some kids will look at this, and try to follow this advice.. there are industry standards for a REASON, and he should at least respect that to mention that.. this is not a mainstream advice which he is giving, and beginners should know that. And to repeat again,, MVVM is NOT a clean architecture in flutter development. If you don't believe me, go speak with cloude 3.5.
fully agreed, Clean architecture kind of old and even some famous framework likr laravel didnt do it. plus MVVM cannot be compared to Clean Architecture i think. you can do both@@aymanbarghout9106
Simply not true. The official flutter channel has feature stacked (which is MVVM) recently. Also, you can do feature based architecture with MVVM and even clean architecture with service locators. It's quite obvious to do it if you think about it.