Flutter State Management Tutorial - Provider + ChangeNotifier, Bloc, MobX & More

📗 Learn from the written post 👇👇
resocoder.com/flutter-state-m...
📧 Get Flutter news 📰 and resources:
👉 flutter.education
👨‍💻 Do you write good code? Find out now!
resocoder.com/good-code-quiz
State management is a hot topic in the Flutter community. You have the default StatefulWidget and then there are literally hundreds of different libraries to choose from. This article will cut through the noise and, once and for all, explain the principles which are valid across many state management solutions. You're also going to see examples of some of the most popular patterns and libraries.
Go to my website for more information, code examples, and articles:
● resocoder.com
Follow me on social media:
● / resocoder
● / resocoder
● / resocoder

[@programan6391]

Very clarifying, now I understand the power of bloc! Thank you.

[@techstudio7331]

This type of tutorial was much awaited now i have gathered hopes to learn a state management solution....earlier i was dreaded by bloc but now i'm gonna try... thànkyou @ResoCoder

[@ResoCoder]

You're certainly welcome 😉

[@aliakkawi4759]

Please make a tutorial on in app purchases for Android and iOS using Flutter. Thanks

[@amankaushik5833]

Thanks a lot for the tutorial!! just wanted to let you know that you are doing a great job Reso Coder :)

[@sanneupane1024]

Your blogs as well as site is amazing. 😮

[@_dinesh]

I was waiting for this video for a loooooooooong time... 🙏🙏🙏🙏

[@9to5Tec]

thanks reso! Excelent work providing good level documentations for developerss;)

[@MichaelNagyTeodoro]

Very good video for those coming from the React mindset.

[@mohabmagdy4155]

Wow THanks Reso like before watching.

[@LukePighetti]

I'm only seven minutes in but as a user of ChangeNotifier as my only global state management I have a couple tips. 1) Use feature sized models instead of individual fields. Think WeatherReportModel instead of Temperature, Precipitation, AirQuality, List. 2) Don't use null checks or have default values. Null coalesce on your getters if there is truly an initial value or have a bool get hasWeatherReport => _weatherReport != null field. 3) Use code generation to back every getter with a private field and maybe a reactive setter if you really want to. You can also do history of your WeatherReportModel generated with your reactive setter along with a revert/commit/rollback method. The pattern is repeatable and it's a great candidate for codegen.

[@vinceramcesoliveros6739]

May I ask why code gens are essential to dart, where when you edit/move the generated dart file(example.g.dart). I still have trouble doing it since code gens don't let you refactor or move files once generated. I need do code gen again.

[@LukePighetti]

@@vinceramcesoliveros6739 You run build_runner watch and it keeps everything up to date. Rebuilds happen in realtime and take about a second each time you save a file. Code gens are essential to most statically typed / class based languages. We don't have the pleasure of wide open dynamically typed objects like in JavaScript which are trivial to serialize/persist/hydrate.

[@LeagueRandomPlayer]

Reso you are a blessing

[@DominikRoszkowski]

Agree 100%

[@alinear1310]

You’re the MVP

[@vincentmontano4518]

States Rebuilder 👍🏼

[@tannermeade]

Ya, I'm kinda surprised Matej didn't go into states_rebuilder more. I feel like I can handle complex solutions that Change Notifier can't easily handle with less code than Bloc when I am using states_rebuilder.

[@ResoCoder]

I've burned myself with states_rebuilder's "magic". ChangeNotifier is dead simple, MobX is more complex but still, it doesn't hide that much from you. This is not the case with states_rebuilder. Also, I'd much rather stick to the tools trusted by the majority of the Flutter community (Provider) instead of using Injectors and other very specific widgets which can be found only in the states_rebuilder package.

[@tannermeade]

​@@ResoCoder It sounds like you might have signed onto some projects that were already using ChangeNotifier and now you are just more familiar with it because of other people's architectural decisions. Which of course is all good because a lot of the decisions here come down to getting work done (done is better than perfect). I enjoy states_rebuilder because I can work with streams and complex state management while being soo much simpler than bloc. I personally love bloc, but I get work done faster with states_rebuilder. My app size doesn't have to grow from adding multiple state management dependencies also.

[@JETLAI123]

@@tannermeade That's true, I'm also writing a complex application with states_rebuilder, so far everything is doing right

[@rydmike]

Very nice explanation of the different principles Matt. Definitely (and as expected) opinionated towards the Bloc library, but well argued. Felix did an outstanding presentation (you probably saw it live in Poland) of the Bloc library that was just published as well by Flutter Europe. His presentation and this video plus your DDD series is really making me lean towards the Bloc lib as well for complex state in large apps. Sure custom encapsulated UI widgets can just be made with stateful widget and setState, and maybe ChangeNotifier if it is a complex big widget, but that is a totally different use case. All about the right tool for the job. Great content as always, looking forwards to the StateNotifier video and continuation of the DDD series.👍

[@eduardselenzow2533]

Oh boy... first of all thank you for your video - much appreciated. When I’ve received the email notification about your new video I couldn’t help laughing. I am currently working on my bachelors thesis where I evaluate state management solutions in flutter to achieve the same goal - help developers to choose a solution for their project requirements. I honestly don’t know if the timing of the video is good or bad :D

[@ResoCoder]

Good luck with your thesis! What could be bad about the timing? 😄

[@eduardselenzow2533]

@@ResoCoder Thank you! :) I guess there is nothing bad about the timing. I am still at the research part and the timing was too good to be true, because it's exactly what I need. So it was kind of unsettling. But the more references the merrier!

[@michaeltolsma7717]

I always imagine that Reso Coder has a body-pillow of Felix Angelov by his side at all times.

[@tadaspetra]

Great video! However, I don't disagree with the points you've brought across, but I get a sense that the negatives of Provider are a bit over exaggerated. For example: I feel like keeping state history is a very specific thing that most applications wouldn't need. And needing to create getters for the private variables, I feel isn't too much to ask for. I feel like the big difference is mutable and immutable.

[@YukiAttano]

well, watching some of the videos from reso coder makes clear, that this guy never has a greater understanding of the underlying system that he pretends to have.

[@h3w45]

well done, thanks.

[@petroniobonavides3530]

@Reso Coder Hello, GETX would be a nice package to show some demo.. State simple/reactive management(without codegen), route Management and Dependencies management in an "box" I have been using that, and it has being a nice and productive tool, to make my code clear and short (i only use stateless classes, it is really cool) High productivity + Huge simplicity. Actually GetX is the best of three worlds.. This si one more good tool for us, Flutter developer.. this si really cool.

[@thaliaamargianou7870]

GetX tutorial series, please! GetX and Hive in a sample project.. would be awesome!!!!! Thanks..!

[@codifigador.zenior]

The old, simple and nice Flux

[@christianonwe2045]

Thanks a whole lot

[@kiyotaka627]

the bloc library looks scary, but it really isn't and the bloclibrary's website examples are amazing to learn

[@haidarrmehsen]

not related to this video but when are you releasing the next part of ddd tutorial?? And thanks for your great videos :)

[@thomasmabika7291]

hey Reso, how about we do this, remember that Weather project you did, the one that uses FakeWeatherRepository? yes, that one, how about you do a series in which you cover all the state management solutions you mentioned in this video using that project? So same project with Provider, MobX, Redux, States_Rebuilder etc. That way we can see exactly the benefits of each solution as well as their drawbacks. I think doing so will be really insightful, especially if you dive a little deeper into the solutions than you usually do. I recommend this approach because, for example in this video you said, we should prefer immutable state management solutions, and you gave two examples, Bloc and Redux but for some reason, you didn't say anything at all about Redux, so with the series, Redux will get its own video and will see exactly where if falls short. and to make things a bit more interesting, how about using a real weather api, complete with exception handling and testing, and even user authentication.

[@eduardselenzow2533]

Hey Thomas, I can understand your wish to see Reso make a series about state management solutions in depth implemented in the same example application. But to do so it takes a lot of time and the outcome will always be subjective. By subjective I mean that only if you've implemented the state management solution by yourself you can get a feeling if you'll like it or not and furthermore see its drawback/benefits. Brian and contributors offer a repository where you can see different state management solutions used to implement a todo list app. Here is the link to the repo: github.com/brianegan/flutter_architecture_samples But to be honest, looking at the examples only helped me to see how they get implemented. I am currently working on a project where I am rewriting Felix Angelov's weather app example with different state management solutions to gain some knowledge and be able to make a researched statement. So if you want to get to know some of the benefits and drawbacks of the state management solutions, I advice you to do something similar. How about forking Reso's finished code from the DDD series and rewrite the application layer with for example mobx.

[@Cherupakstmt]

You could have include states_rebuilder also. It looks very easy in comparison to bloc. Would you recommend it over bloc?

[@julions777]

He also has a tutorial on states rebuilder, in which says that it is the easiest state management solution he has tested, it looks he changed his mind

[@JETLAI123]

States_Rebuilder now supports ReactiveModel for both the immutable and mutable object's state, it's a hybrid solution of the observer pattern with dependency injection. Is it better to get a deep review? From my experience, it's quite handy and good performance, very easy to implement it with TDD or DDD without a lot of boilerplate. I'm not saying that it's better than BLOC/ Redux, still, it's a good consideration.

[@rahulmp7109]

Good

[@Victoruvarov23]

Using an enum for the state in the change notifier will remove the need for is loading, is initial

[@ResoCoder]

True but it's still much less expressive than a separate state instance.

[@joeng7424]

and also eliminates the ability to having parameters inside your states

[@mosth8ed]

Great tutorial, as usual, but would it be possible to use a darker background when showing slides? The bright white is killing me.

[@islandcoder876]

Great explanation on state management

[@ResoCoder]

Glad you think so!

[@reggieescobar2772]

Wait up! Can I use provider and Bloc together? Provider for passing values within a widget tree and Bloc for showing different states of my UI??

[@PankajNikam]

Once again, as always the tutorial is good. Thank you so much 😊 I just have a question - what do you think of Flutter for Desktop? Do you think they will come out with final release for desktop?

[@ResoCoder]

You're welcome! I hope a stable desktop Flutter version is near but I have no clue. There's no reason why they wouldn't release a stable version in the future though.

[@yashraut19]

1-1.5 year maybe

[@kopianan]

Hei. im waiting for your DDD tutorial ... pls

[@h3w45]

why there is no still state notifier video?

[@8VT0]

You can change the title for Flutter State Management Tutorial - I love BloC... + the others.

[@bobthebuilder6715]

:D :'D

[@tintin537]

Hello reso, When are you gonna continue the DDD series?

[@ResoCoder]

Should be out on Monday.

[@tintin537]

@@ResoCoder Well thank you and impatiently waiting for it.

[@tintin537]

By the way amazing explanation about state management. There are a lot of people out there which they can't be convinced that immutability gives the code much more stability and kinda gets rid of the fragility of the code. If you could deep dive into it and give a good video about that I'll appreciate you very much. And I have an idea for the video which is going through the bad symptoms that are caused by not using immutable state management in large applications in the long term.

[@aytunch]

@@tintin537 Actually this is a great idea for a video or article. The importance of immutability in Flutter state management: bloc preferably:) I hope @Reso can take on this

[@bikashrai1]

One question, what is the difference between a Cubit and a StateNotifier?

[@gabrielribeiro8619]

I think both are very similar... But when the video was recorded, cubit didn't exist yet

[@zanfras1149]

Hoping for BloC with Freezed tutorial. Great video tho!

[@officialismailshah]

why you didn't talk about getx??

[@yakine13]

2:43 Please someone tell me how to make your mouse cursor like that!

[@ResoCoder]

If you're using Google Slides like me, there's an option to enable "laser pointer" mode.

[@yakine13]

@@ResoCoder Thanks man, Can you please check my Facebook message? I have a small donation to make in exchange of your guidline for my project, I'm wasting time running in every different method I find lol

[@web3tel]

Sorry, I am missing some point. Why encapsulating state into hierarchy of classes including InitialState is not compatible with ChangeNotifier approach? Why is it assumed that it inherently require keeping state in bunch of properties as opposite to one state variable?

[@ResoCoder]

That's why I put the little asterisk * on one slide. Most people use ChangeNotifier with multiple properties. If you're using only one, I think StateNotifier would suit you better.

[@web3tel]

@@ResoCoder Thank you

[@d34dsouI]

Here is the challenge: Write the same app with Redux, Bloc and MobX to prove that your clean code architecture is really independent of the state management approach used.

[@VimalMistry10]

I tried all. I am one man army developer. Finally selected Mobx and completed 4 project with it. BlocLibrary is overrated.

[@xxXAsuraXxx]

Bloc pattern is so freaken complicated

[@arifikhsanudin9724]

Hi

[@web3tel]

typo? bool get isLoading => isLoading; // should be isLoading => _isLoading

[@ResoCoder]

sure 🤦‍♂️

[@pythonwithlyrics9323]

Please Reso you can make provider with firebase

[@bartekpacia]

IMO State management is the biggest pain in the ass in Flutter, maybe that's because I'm used to Android's MVVM but really boi, the time Flutter saves me when creating UI is then wasted when doing repetitive BLOCs over and over.

[@LukePighetti]

Use what you know. Why can't you do MVVM in Flutter?

[@sergey_molchanovsky]

In my opinion, those ChangeNotifier drawbacks are far-fetched, and the review in general is biased. It's like "there's a ChangeNotifier pattern, but it's a crap, now let's look at more advanced patterns". At first, I'm not quite agree with "don't call it "Provider", call it "ChangeNotifier" statement. Provider is primarly used for its ChangeNotifierProvider. Provider is not a simple tool for delivering data to your widgets (of course, you can use it this way), but also for effective updating your UI according to data changes. So when I say "Provider pattern" I surely mean "Provider+ChangeNotifier". Secondly, seems like you don't quite understand this pattern. You should keep your ChangeNotifier store simple. You don't need any of those _initialState, _isLoading, _result fields. Store can't be in "loading" or "error" state! You're trying to mimic a Bloc "FSM" approach here, but you don't need it. You just hold your private data, public getter (returning a copy of original data - it's not a boilerplate, but a way to protect your inner data from accidental changes and not to expose it), and action methods for finding/mutating the data (basically CRUD operations) with notifyListeners() calls for updating the UI. You don't store or handle erros in your Store. If you fetched something from server and got a bad response, you just throw a HTTPException, and show an alert in your UI. You don't store a loading state. You just ask a Store to fetch data and show loading on the UI side with FutureBuilder, or manually turning CircularProgressIndicator on and off. The code is bloated much more with BLoC. The only argument I'm agreed is that you don't have immutable states history, and thus can't do Undo/Redo "time travel", or to save the whole app state, with ChangeNotifier approach. But agree, there's no so much applications where you really need it (I can't remember any). Pros of using Provider+ChangeNotifier approach: - You do just what you wanna do. If you want to add item to your list, you just do it! You don't need to dispatch an event, pass it through a bunch of reducers or map functions and observe a state changes. Easy to read, easy to maintain. - You completely control your UI rebuilds, and you always know when and which part of it rebuilds. You can optimize your rebuilds with Consumer (that has a 'child' property to exclude child from updating). You can optimize even more with Selector (subscribe only to necessary parts of your Store to watch). - You don't need any "middleware" or "reactions". Actions can be asynchronous. You can do "optimistic updates" with ease (rebuild, then undo and rebuild again in a same action).

[@barsidemen5208]

Thanks for putting another perspective. Consumer()'s optimization is really important in this discussion, yet, I'd like to find out your views on BlocConsumer()? Can't we use it the same way as Consumer() in the Provider pattern?