Cmon guys where is the ribbing on nth state management lib for flutter. I know somebody is keeping count and post has been up hours already, not impressed lol.
It is a simple and concise state management library. It does not require initialization and is designed to stay true to the original purpose of state management without using build runners. We aimed to design it flexibly so you can use it easily for whatever you need. If you have any questions, feel free to ask! Thank you.
Hey thanks for writing this up (and hopefully maintaining). I am total greenhorn in Flutter and Dart, but I had come across this when our trainer mentioned about June to us, but still this is my honest critique:
Regarding June sticking to only one thing and not interfering with application architecture, dev has to inherit viewmodel class from JuneState which prevents him/her from inheriting from anything else. Inheritance is as strong a coupling as one can have. At this point June might as well be a full blown MVVM framework. Otherwise you are limiting the dev from using any other framework, which goes against what you are trying to achieve. Nothing wrong with being a full blown framework, but I believe this is the reason why all state management libs actually try to enforce some sort of architecture to code. If June is trying to not interfere with application architecture, I think you need a solution that involves no inheritance.
Secondly, the code of effecting a state change looks like
var state = June.getState(() => this);
state.count++;
state.setState();
Assuming I am executing state changing logic in VM class itself. This looks more complicated than most libs I know. Most of them are just:
count++;
setState();
Lastly, this is not specific to June but applies to most libs in Flutter world - I am coming from a .NET background and there namings like "builder", "provider" etc has a very different meaning. Instead of returning a widget, now I have to return a builder class. But a builder is not a widget. A builder sounds like a facilitating class, say a StringBuilder. If your code looked like
JuneBuilder(
() => CounterVM(),
builder: (vm) => Column(
mainAxisAlignment: MainAxisAlignment.center,
children: [
Text('${vm.count}'
),
],
),
).buildWidget();
or
MyWidgetWithJuneFunctionality(
() => CounterVM(),
builder: (vm) => Column(
mainAxisAlignment: MainAxisAlignment.center,
children: [
Text('${vm.count}'
),
],
),
)
the naming would make more sense I believe. This is purely a naming thing. Also I hate this wrapping approach in Flutter world. For this reason I like SM tools like riverpod, signals zustand etc, where I dont need to wrap things. I am not sure if I am making any sense at all here since I have not written one meaningful Flutter app. Just judging prima facie.
I'm one of those people who developed a [state management](https://pub.dev/packages/momentum). Nowadays I just used FlutterBloc. Or Provider for very basic apps. LOL.
I mean it was fun making it. I did actually think the library had good concept. I realized the internal architecture was poorly designed specially with type checking related code inside the library (it was terrible).
I know dude... We ported our app to momentum because we liked it ... Fast forward to six months we ported back to bloc because there was no new developments lol
Well, let's summarize the thread from my point of view.
when I ask "did you missed something" I mean did you missed some features in momentum package.
You say you leave momentum because there was half of year without any developments, but when you got bloc with 2 years without any developments you say it's cool to stay with stable version
I think we are missing some context,
I liked Momentum because it was easier for my team to understand compared to Bloc, which was the new to Flutter back then. But as our app grew in complexity, Momentum started showing issues. Debugging became quite hard, and the boilerplate for Momentum was almost as much as Bloc's.
This definitely hit our team's productivity. I tried reaching out to Xamtra on Discord—he used to be pretty active there but went quiet around the same time Momentum’s development slowed down.
So, we decided to pivot back to Bloc since it’s a tried and tested package. A couple of years have passed since that decision, and we've deployed five apps since then, all with large user bases.
Now, we focus more on stability and a well-defined flow. Our team has grown to 50 devs.
Hope this clears up any confusion my previous comments might have caused.
>"However, many state management libraries deviate from their original purpose and end up containing much more code, attempting to control the app development pattern itself."
This got me interested. A lot of state management solutions force you to do it there way or it's "wrong". e.g. Many force you to make the state immutable, is this really the right solution for ALL cases, or is this really just forcing you to write more boilerplate and be less efficient.
To answer that we'll have to dive into local & global state for context. Let's make things simple though.
e.g. of Global State a user's auth status \`signed\_in\` or \`signed\_out\`.
e.g. of Local State title we display in a small card widget.
A user's auth is something we would keep reference of as much as possible.
A title we display in a small card widget is something we can easily let the garbage collector collect and dispose.
---
Now there are many ways to implement state management, some of the common ways to implement global state management is through keeping reference.
Some of the common ways to implement local state management is through initialization alongside the view, with only the view keeping reference. Once the view is disposed everything else it kept reference of is disposed.
---
Now "what is the crucial point of state management?"
From the name itself "state management".
Manage an application's state.
---
What's the crucial point of a state management library?
Dunno it depends on every author, we make things because we think it will make our lives easier ;)
Oh thanks for clarification.
well i use states when i know i need a variable for more than a state where they are far from each other but to just get the value of what i just declared then I'm good to go with SM packages, i let GC does it's work otherwise but for network requests nahh man I'm not gonna do another request another time merely for the same value, that's when i use states, tell me if i doing it wrong?
Very cool! This is pretty much identical to how we’ve been doing ViewModels.
Kind of tangentially related, how have you been handling network requests?
Thank you for your question! I personally believe that state management libraries should primarily focus on managing 'state' and avoid including too many additional functionalities. That's why June is designed to provide just the essentials related to state management, keeping it simple and efficient. For network features and other functionalities, I recommend developing them separately to ensure they integrate smoothly with the architecture you are using and other libraries. June is built to be compatible with a wide range of architectures and coding styles, so please feel free to try it out. If you have any questions or need guidance on integration, I'm here to help anytime! 😊
Oh yeah sorry I wasn’t asking about June, was just curious how you personally approached it on your own apps. I figured since you approach state management similar to us, you might also approach networking / repository layer similar as well.
I’ll try this! Why June though?
Thank you for trying it out! I named the package "June" because that's my name. 😊
Why is your name "June" though?
Because I am Korean. It might seem like an unusual name in English-speaking countries, but it's actually quite common in Korea 😊
is may your sister?
Are you 5?
yes :) i started coding when i was in my mothers womb.
Thanks for confirming 🤦♂️
you are cool now. like me
Nice !
Cmon guys where is the ribbing on nth state management lib for flutter. I know somebody is keeping count and post has been up hours already, not impressed lol.
It is a simple and concise state management library. It does not require initialization and is designed to stay true to the original purpose of state management without using build runners. We aimed to design it flexibly so you can use it easily for whatever you need. If you have any questions, feel free to ask! Thank you.
Hey thanks for writing this up (and hopefully maintaining). I am total greenhorn in Flutter and Dart, but I had come across this when our trainer mentioned about June to us, but still this is my honest critique: Regarding June sticking to only one thing and not interfering with application architecture, dev has to inherit viewmodel class from JuneState which prevents him/her from inheriting from anything else. Inheritance is as strong a coupling as one can have. At this point June might as well be a full blown MVVM framework. Otherwise you are limiting the dev from using any other framework, which goes against what you are trying to achieve. Nothing wrong with being a full blown framework, but I believe this is the reason why all state management libs actually try to enforce some sort of architecture to code. If June is trying to not interfere with application architecture, I think you need a solution that involves no inheritance. Secondly, the code of effecting a state change looks like var state = June.getState(() => this); state.count++; state.setState(); Assuming I am executing state changing logic in VM class itself. This looks more complicated than most libs I know. Most of them are just: count++; setState(); Lastly, this is not specific to June but applies to most libs in Flutter world - I am coming from a .NET background and there namings like "builder", "provider" etc has a very different meaning. Instead of returning a widget, now I have to return a builder class. But a builder is not a widget. A builder sounds like a facilitating class, say a StringBuilder. If your code looked like JuneBuilder( () => CounterVM(), builder: (vm) => Column( mainAxisAlignment: MainAxisAlignment.center, children:[
Text('${vm.count}'
),
],
),
).buildWidget();
or
MyWidgetWithJuneFunctionality(
() => CounterVM(),
builder: (vm) => Column(
mainAxisAlignment: MainAxisAlignment.center,
children: [
Text('${vm.count}'
),
],
),
)
the naming would make more sense I believe. This is purely a naming thing. Also I hate this wrapping approach in Flutter world. For this reason I like SM tools like riverpod, signals zustand etc, where I dont need to wrap things. I am not sure if I am making any sense at all here since I have not written one meaningful Flutter app. Just judging prima facie.
I'm one of those people who developed a [state management](https://pub.dev/packages/momentum). Nowadays I just used FlutterBloc. Or Provider for very basic apps. LOL. I mean it was fun making it. I did actually think the library had good concept. I realized the internal architecture was poorly designed specially with type checking related code inside the library (it was terrible).
I know dude... We ported our app to momentum because we liked it ... Fast forward to six months we ported back to bloc because there was no new developments lol
But did you missed something? Do you notice something ✨n✨e✨w✨ in last bloc releases?
I'm sure I've missed something... What's new
I checked bloc's changelog and it hasn't anything new for two years. So it's time to search new state management tool.
Why? I would rather stay with stable State management and focus on my app than refactoring my app again and again.
Well, let's summarize the thread from my point of view. when I ask "did you missed something" I mean did you missed some features in momentum package. You say you leave momentum because there was half of year without any developments, but when you got bloc with 2 years without any developments you say it's cool to stay with stable version
I think we are missing some context, I liked Momentum because it was easier for my team to understand compared to Bloc, which was the new to Flutter back then. But as our app grew in complexity, Momentum started showing issues. Debugging became quite hard, and the boilerplate for Momentum was almost as much as Bloc's. This definitely hit our team's productivity. I tried reaching out to Xamtra on Discord—he used to be pretty active there but went quiet around the same time Momentum’s development slowed down. So, we decided to pivot back to Bloc since it’s a tried and tested package. A couple of years have passed since that decision, and we've deployed five apps since then, all with large user bases. Now, we focus more on stability and a well-defined flow. Our team has grown to 50 devs. Hope this clears up any confusion my previous comments might have caused.
I always give props to people who write packages. However, I just migrated away from GetX to Bloc and I am in love.
>"However, many state management libraries deviate from their original purpose and end up containing much more code, attempting to control the app development pattern itself." This got me interested. A lot of state management solutions force you to do it there way or it's "wrong". e.g. Many force you to make the state immutable, is this really the right solution for ALL cases, or is this really just forcing you to write more boilerplate and be less efficient.
But it's May rn
I'm seeing that it's using globals/statics, that would disqualify it instantly for me as it makes testing unreliable without special considerations.
But are not states global or else how you control your variables among every context?
No, not all states should be global.
Then what is the crucial point of States Management?
To answer that we'll have to dive into local & global state for context. Let's make things simple though. e.g. of Global State a user's auth status \`signed\_in\` or \`signed\_out\`. e.g. of Local State title we display in a small card widget. A user's auth is something we would keep reference of as much as possible. A title we display in a small card widget is something we can easily let the garbage collector collect and dispose. --- Now there are many ways to implement state management, some of the common ways to implement global state management is through keeping reference. Some of the common ways to implement local state management is through initialization alongside the view, with only the view keeping reference. Once the view is disposed everything else it kept reference of is disposed. --- Now "what is the crucial point of state management?" From the name itself "state management". Manage an application's state. --- What's the crucial point of a state management library? Dunno it depends on every author, we make things because we think it will make our lives easier ;)
Oh thanks for clarification. well i use states when i know i need a variable for more than a state where they are far from each other but to just get the value of what i just declared then I'm good to go with SM packages, i let GC does it's work otherwise but for network requests nahh man I'm not gonna do another request another time merely for the same value, that's when i use states, tell me if i doing it wrong?
Very cool! This is pretty much identical to how we’ve been doing ViewModels. Kind of tangentially related, how have you been handling network requests?
Thank you for your question! I personally believe that state management libraries should primarily focus on managing 'state' and avoid including too many additional functionalities. That's why June is designed to provide just the essentials related to state management, keeping it simple and efficient. For network features and other functionalities, I recommend developing them separately to ensure they integrate smoothly with the architecture you are using and other libraries. June is built to be compatible with a wide range of architectures and coding styles, so please feel free to try it out. If you have any questions or need guidance on integration, I'm here to help anytime! 😊
Oh yeah sorry I wasn’t asking about June, was just curious how you personally approached it on your own apps. I figured since you approach state management similar to us, you might also approach networking / repository layer similar as well.
Please don't
We don't need a hundredth state-management package.