GetX 5 #2889
Comments
If you don't use any of the above, the chances that you don't have breaking are high. Note: We will probably split the package into smaller packages for those who only want to use part of the package. The Get package will continue with all the code, but there will be other smaller packages with only part of the implementation. Each resource will communicate with the others through Middlewares. Ex: Navigation will trigger events. Dependency injection can listen to these events to decide when to delete a controller. State management and dependency injection cannot be separated, because the latter depends on the former at any time. However the routing, connection with the api (get_connect), and the animations api, may not be part of the scope of many projects, so let's insert it in GetX, but allow people to use GetX's state manager without they also. Obviously, everything will work better together (since the automatic deletion of controllers integrates well with the routes api), but if someone wants to use it in a different way, that's fine. |
|
all the best to you. |
|
Version management is very confusing, i can't even find the properly branch or tag or commit id of version 4.6.5. |
|
i appreciate your time and effort to provide significant solutions but i have a question for you are you working on this alone ?? |
|
GetX has already saved a lot of time, and now it's time to use that time to embrace change. |
|
Thank you, for giving a update and wish you all the best |
|
Thanks for the update and the effort to make this package evolve in the good direction. |
|
Thanks for trying to keep this great package up to date. We really appreciate your effort. |
1 similar comment
|
Thanks for trying to keep this great package up to date. We really appreciate your effort. |
|
Keep up the great work. Your package help me a lot |
|
you're rock bro |
|
go bro....fuck all haters |
|
getx is the best in flutter world! |
|
I'm finally able to resolve this issue, thank you very much. |
Please tell how you managed that. |
|
you're rock bro |
|
@jonataslaw you are the very good and intelligent programmer in the Flutter world |
|
I don't see the update on pub.dev. Is the update not available yet? |
|
separating multiple packages is a really good decision |
|
Great to hear that GetX 5 is now on track, our applications are using GetX from start, and it's so easy to new members to catch and understand our codebase because of the simple of this framework, that's why we use GetX over Riverpod, BloC, Provider,... |
|
when will the new version be published? |
Next year i guess |
|
Hahaha I'd rather be the guinea pig than push an update and you guys be mine, if something breaks I can fix it quickly. |
Noice 🥳 |
Waiting for new challanges ✌️ |
great |
Excited for the update. |
go go go |
|
looking forward to new version of your awesome work. |
|
Dear Please ask community to help you out and release the next beta verison |
|
Use https://pub.dev/packages/refreshed |
|
Awesome package! I've been using it for three years, but it seems like the support for this package hasn't been very good for the last five to six months. Additionally, in the developer community, many developers spread rumors as if it's going to end badly. @jonataslaw should interact with the users of this package as soon as possible. If not, we can migrate to another state management timely. |
|
refreshed is good, but i want official GETX to update atleast just update some dependencies so we feel secure and stable. |
|
kindly contribute to GETX as well |
|
Dear Dev, I know i am asking too much, but my whole project is stuck for months due to GETX no updating... kindly upgrade some dependencies atleast and give a minor update |
|
We don't want to use refreshed, thr release candidate is working fine, just
needs some Minor updates..
…On Mon, May 6, 2024, 9:32 PM Hayat Bangash ***@***.***> wrote:
Awesome package! I've been using it for three years, but it seems like the
support for this package hasn't been very good for the last five to six
months. Additionally, in the developer community, many developers spread
rumors as if it's going to end badly. @jonataslaw
<https://github.com/jonataslaw> should interact with the users of this
package as soon as possible. If not, we can migrate to another state
management system in a timely manner.
—
Reply to this email directly, view it on GitHub
<#2889 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIRXJSGW5NCL6R3RC32YD7DZA6WAFAVCNFSM6AAAAAA372ZIUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJWGQ2DONJRGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
please read the the licence, let the author in quiet and stop spamming |
|
[5.0.0-release-candidate-6] can it be released given the pull requests are tested and working for flutter 3.22 |
|
In the meantime, it's better to use the previous version of Flutter than the latest version that brings problems |
No, u can use latest: get: |
|
Is it time to finally stop using GetX since it seems like GetX is not properly maintained anymore and GetX 5 is never going to be released? To be on the safe side, it seems like a fair step. @jonataslaw You have committed the last two times; @Aniketkhote what is your opinion on this? |
|
@fisforfaheem how about get_storage? get_storage dependency on getx |
|
@mohsinnaqvi606 brother the dev seems to be active, just not reluctant to release updates.. However our best bet is to depend on the solution i provided and if everyone uses it, and then find issues it would help a lot for further development. |
|
@fisforfaheem what is your solution? |
Us this instead of fixed getX in pubspec.yaml |
|
Don't pay too much attention to some people's gossip, concentrate on doing what you like and think is right. Come on, brother, I support you. |
|
@jonataslaw any update on package????? |
|
Getx is one of the most niubibility Flutter tool libraries, and hope Getx can stay true to its original intentions, continuously improve, and do what is right and beneficial to the Flutter ecosystem |
|
I'm very, very disappointed with this package. It's the simplest and easiest one, with great helpers, tools, and everything you need. But unfortunately, its future is very ambiguous, and you can't rely on it. No updates, no contributors, and no clear versioning |
|
@jonataslaw kindly clear his doubts |
|
I believe everyone shouldn't be so quick to jump to conclusions. The author just needs more time to complete his plan. In fact, the author hasn't abandoned GetX; he is working hard on another direction, but some people just haven't noticed. Encouragement from the community is what motivates the author to keep going, whereas criticism will only have a negative effect. 
|
|
i appreciate your clarification @giantss so please don't have a look on the other because there is here a wave of criticism and clueless of the package and there is a lot of developers here have raised some claims and demands to not use GetX as it is not a reliable package and use another state management our developers here and to be precise most of them think that getX is a statemanagement only😂 so for that no worries i trust in the creator of the package and very soon will be considered as flutter favorite🤗 |
|
GetX will remain the most liked package on pub.dev IMHO: Let him cook |
what about last 1 month |
|
Can't you focus primary on state management and build it as a separate package, we have a better solution than getx for all other features you provide. rx widgets is the only need so we are free to use any package for any purpose |
|
Yeah i agree. Getx better focus state management. Thats it. Plus their rx is so simple and thats good. Storage? Network? Localization? I dont need it. I like native or other libs for that. |
|
Yes agree with u we just need next getX no other useless stuff |
and others
I think I have failed to be conservative.
GetX basically hasn't changed since its first version (only the RxTypes have changed due to Flutter updates), and I've been trying to keep breaks to a minimum for each update, after all, this is one of the things I like (or liked) the most in using a framework, not having to tinker with its code for a long time.
However, version 5 became a headache. We were migrating the api to navigator 2 completely without ANY break, this is insane. I had to keep a bunch of code I didn't want to maintain compatibility.
However, the truth is that Flutter has matured over the years, and so have I, and there are many things that I just don't see any sense in anymore.
GetWidget, for example, is a widget that prevented Flutter from updating a widget for performance. This was identical to React's PureComponent, not present in Flutter, however, it complicated the api, and brought more bugs than benefits, simply because it was impossible to modify it. With current applications that have dynamic themes, this has become useless.
Also, it seems that GetX users have come to demonize BuildContext, and well, that might have been my fault, after all, that was GetX's description. However, our role was to provide parallel dependency management approaches, not based on BuildContext, but that didn't mean we stopped using it. Today there are people who use Get.width within widgets, which is a headache, since it does not receive dynamic updates, for that there is context.width, however, despite this being in the documentation, this seems to be ignored by part of the users.
That way, I ended up pushing an update forward, just out of fear, fear of having to refactor my projects, fear of causing too many breakings, and the project went a long time without updates.
However, I think we can be better, I think we can have a solid, modern foundation (the current one was written 4 years ago), and so I think we're going to have some changes.
I created this issue to share all the changes I'm going to make in version 5, to serve as a guide in case something breaks.
This does NOT mean that GetX 5 will be full of breaking changes, just that it will have small breaking changes, like every major package update.
The text was updated successfully, but these errors were encountered: