1

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
2

Congratulations. You made it harder and more complicated than anything else.

2 Likes
3

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.

2 Likes
4

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

2 Likes
5

Thanks for calling us stupid.

At least we can KISS, right?

6

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 :slight_smile:

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 :sweat_smile:
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.

7

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. :cry:

8

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.

9

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.

10

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.

11

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.

12

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.

13

Hi, it seems you put a lot of work into that and that’s great you had so much drive to do this :flexed_biceps: .

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 :wink:

2 Likes
14

I have only one question. Why?
The only logical reason I can fathom is that you had money that you needed to spend/appropriate

15

To @escamoteur

Oh no, it was not really about your package’s functionalities. It was stable then so there should be no issue report from me.

I was talking more about the structure or architecture. At that time, I did not have enough experience to deal with it so that is why I said it is too personal. I do not know how to describe it.

You can also refer to me below comment for more about my idea.

16

To @mihalycsaba

I will work on simple example; starting with Counter I guess. It is good enough.

My idea and work are not like to any exiting statement so I cannot point out which one is comparable to mine. You can refer to my explanation below.

To @gawi151

Yes, it is the tree-layout structure that I propose for managing all components in projects. You point it out correctly. At the beginning, I had looked at the Flutter tree (ProxyWidget for particularly); and tried to integrated it with my concept but they does not work along well.

In general, as said in my documentation, despite of different available approaches (bloc, get_it, provider, InheritedWidget, …), they all follow one idea: lifting the state up (Flutter suggest it). We will have Observables and multiple UIs subscribe to them and update their state (or rebuilding UI) whenever their Observables change.

My approach is against it - there would be no such kind of Observable. Instead, all components are observables, subscribed by its direct parents. For example, a Toggle is an observable; which is subscribed by the parents using it, such as a HomeScreen. When toggle’s state changes, HomeScreen will react accordingly - trigger the callBack. When needed, HomeScreen is also the object who “commands” the Toggle to update its state as well.

It also applies same thing to other components that is not UI as well: Data providers, Repositories, … They will be attached into the tree; they have state just like UIs and obey same communication rules.

At first, I did love Provider, get_it, then Bloc. They provide convenient ways to manage app state. But when the app started to scale up; features by features. The ‘lifting the state up’ exposed many weakness: harder to debug, the widgets expand too much because of subscribing to many Observables, limit the flexibility of allocating logic, … I can’t show you all exactly details for each weakness because to do that, I need to reproduce the whole projects to demonstrate the issue details; and that projects will be at least five times bigger than the example and it will violate the confidential policy.

My approach has weaknesses too. It is more imperative, which is currently considered not good as declarative. It requires we have to implicitly update UIs. And worse, we have to inject the data deep down to lower components one by one. But actually after testing by applying my approach to the reproduced similar projects, those inconveniences were not bad as I think; and they are worthy because the existing issues were resolve by root. Again, I cannot show you the details so all of these are very subjective. All my work of this package has been resulted from my real experience.

Because at the moment my package is very discouraged to learn, I can only suggest that you just keep the mentioned concept and idea in mind for now (ignore the paper implementation). When you work with your projects and sometimes meet any drawbacks, confusing and frustration, maybe try to picture what if you apply the concept into the projects. If somehow it makes sense you can comeback and read more my package. If not, you are in correct direction :grinning_face_with_smiling_eyes:.

Bottomline, go for what you are confident with and have experience with.

17

Never hurts to have something different. I still didn’t have time, but now I really want to try the example code. At first look, your package has overlapping features with riverpod.

Isn’t this slow?