We have developed a new state management for Flutter app. Our approach is very different from existing common statements so it takes time to comprehend. We hope that our approach will be worthy to your time spent.
The pattern is trying to
- Make the components (especially UI or widgets) easily reusable by removing the their dependency to observables.
- Introduce more unified architecture by treating components equally. There would no distinguish layers: presentation, repository and data.
- Add flexibility to the way of allocating the code by removing the abstract and ambiguous concept of separating between UI and logic. From that, it reduces the potential contain-too-much-code issue in one component.
Please refer to paper | Flutter package for the package’s info and documentation.
Please have comments for any concerns and thought about this package.
Thank you for your time
1 Like
Congratulations. You made it harder and more complicated than anything else.
1 Like
Honestly, why make things so complicated.
State management is just about rebuilding the UI when your data changes.
We have more than enough good solutions. One of the easiest one my watch_it but others too.
From reading your docs I don’t understand why you add an additional abstraction over observable data structures? That might make sense for a very specific application but surely not as a generalized pattern for simple to understand architecture.
1 Like
You should work on your documentation, there are spelling and mostly grammar issues, which makes it hard to understand what you meant.
Also the example is too complex. Your basics chapter just shows a regular flutter app, I’m not sure why… Try to explain less with your words more with code snippets, using paper.
Look at the provider readme, it is straightforward, you can understand and start using it without looking at their example. Most packages I use, I rarely had to look at the example app, unless it’s some big package with a lot of functionalities or their readme is lacking.
I would advise you to change the first example to as minimal as possible, to just show how the basic data change and widget rebuild works, that’s what the majority wants from a state management solution. You can demo navigation, data fetching and whatnot later a separate app/apps, maybe these are good to have in a state management package but not necessary.
Yes a complex app is good too, just not everyone has the capacity to decipher and understand it when looking for state management. You can have multiple example apps for different topics. Also, put comments in your example app, it’s long and I have no idea what things do and why they are there.
Maybe it is because it’s sunday and I only spent 10 minutes reading the docs, but I have no idea how to start for example a simple shopping list app with paper. Maybe if I open it in an IDE and run it I will have an easier time. It just looks complicated at first look.
For example how would you do this with your solution, it’s a minimal app using callbacks and setstate, you should do something like this to explain the basics: DartPad
1 Like
Thanks for calling us stupid.
At least we can KISS, right?
Thank you for your comments! @escamoteur @mihalycsaba
This package is not only about state management, but also about make the project’s code base easier to maintain. To me, state management is not just simply rebuilding UI; it affects a lot to how we are able to debug, expand and maintain the project.
I completely understand your negative feels to my work because it looks complex to digest. It is just that I believe that in exchange of that, we have projects better maintenance ability.
To @escamoteur,
I see that you re the author of get_it, one of the most common package used in Flutter community. It is honored to talk to you. I am really sorry if I have made come negative thought to your package. It is just because of my bad experience when working with it. It is too personal to discuss further so I do not know how to talk about it 
To @mihalycsaba
Thank you for your suggestion! I definitely try my best to update documents. My English is very limited and I am even not good for making documentation in my native language. Therefore, I maybe think about hiring someone to make it better 
Regarding the complexity of the example, I have thought about it but I was just afraid of not encapsulating the main concept within it. My work literally against nearly everything that is commonly accepted and used in market. Therefore, I make it in one big example and guide everyone step by step to comprehend the idea. If you are still interesting and have time, you can create very fresh project and following section any section in Tutorial and reproduce the example. You can init Git to track the changes of new features for every new sections.
To @evaluator118:
I think @mihalycsaba did not mean that. I believe he/she meant that the example is too large and complex than it should be. Because this is about learning something new, he/she suggested to make it as minimal as possible. Many don’t have time for it and may be discouraged. 
why are you so salty? everyone is on tiptoes around you, yes not everyone is going to go through a bigger example just to see how stuff works. I was just trying to be constructive about the docs.
No need to hire anyone, LLMs are almost perfect in one thing, which is translation. Your english is good enough to see if it was translated correctly.
Still there might be people, that just want one thing, to update widgets. Maybe that part is not that complex, if possible it would be nice to have some simple examples. But if it really was not made for simple widget updates, it’s fine. Just improve the docs and put comments in the example app, that would be really helpful.
I’m still new to this, so I didn’t try packages that do too much, I can get by with the basic provider+go_router combo. Maybe it’s easier to work with something that does everything in one package, I don’t know.
Also it would be good if you could provide a comparison with existing state management solutions, like riverpod. I don’t know what else is comparable.
Hmm, why did you never file an issue if you had problems with get_it.
Did you ever had a look at watch_it or read my article on architecture?
I was one of the first writing on Flutter Architecture in 2018 so I believe to have quite some experience. And I don’t think paper makes like easier but more complex.
To be fair, not everyone is going to take time to file an issue to a random package they don’t understand. I certainly didn’t do that for provider/bloc cause I thought “well this is too confusing, I’ll just go somewhere else”.
Btw, in regards to watch_it, being a get_it user, I discovered watch_it by a random coincidence. Not sure if the docs improved from before, and you have cross links between the two packages, but it wasn’t as easy when I was starting out. I’m the the rebranding you started would help with this.
Re: documentation
Personally I find that all state management docs are lacking. Provider/Bloc through at you a bunch of concepts and try hard to explain them but it’s not really helpful. The attempt from the OP is kind of similar in this regard. Not to say it’s a bad idea, but introducing new concepts and vocabulary requires much more effort in explaining and guiding the user.
This is even harder when the user has pre-existing knowledge of more common patterns like MVC and whatnot. They try to mentally map the new concepts to those they are used to, which does not necessarily work well.
This is, by the way, the reason I stuck with get_it and watch_it. Even though the docs were fairly basic, I didn’t really need to learn much new. DI, Singletons, Factories, etc, all these concepts are the most common design patterns. And watch_it is similarly just a wrapper around ChangeNotifiers that conveniently hooks into the widget layer with almost zero boilerplate. Brilliant idea.
Absolutely understand that jot everyone open a ticket but if someone tells me about painful experiences then I expect that he spent time with the package and given the 1000s of happy users I really would have loved to know more about his problems.
I try to publish simple straight forward APIs and I am happy for any feedback how to improve the docs.
Hi, it seems you put a lot of work into that and that’s great you had so much drive to do this 
.
As I read a little bit of getting started to the place where I read this:
In the Paper pattern, all objects have to be placed in a tree-layout architecture as introduced in Concept, including the Repositories, Data Providers if they are created. It also means that they have states. Yes, Data Providers, Repositories, or even Databases on the local or server-side have states.
When I read this it came to my mind that what you are doing is basically what Flutter is doing - the tree.
If I understand it correctly you want to stay way from Flutters concepts but in a result you created something that resembles it very much.
I’m not convinced with your approach. For me it would be just duplicating the widgets with your custom solution.
I’m open for discussion but to me it seems you should really look again what Flutter is offering and master that.
Best of luck with your package 
1 Like