getx

getx copied to clipboard

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.

1. GetWidget. GetWidget will NOT prevent further widget updates. Perhaps it will be merged with GetView, and perhaps it will have one of the following functions:

• Auto track of updates: Not sure yet, but maybe this will be added
• Scopped Widget: It can create a scope to pass a copy of your controller to your children. This controller can be accessed through the BuildContext.

2. Nested Navigation: Previously we used onGenerateRoute to use nested navigation. This won't work since version 5 uses Navigator 2. We'll use RouterOutlet instead.

3. Whoever uses the "change" immutable api will have some breaks. RxStatus for example will cease to exist.

4. Bindings will change, instead of an empty method you will have to return a List<Binding>. This will allow you to inject the dependency with a scope. Why that? Well, if you have a "ProfileController" controller, and a feed where you can endlessly browse through countless profiles, you'll need something similar. I think the current approach is too "hacking", and you have to use tags to generate dependencies. This usually brings a headache, so let's change.

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. Please prepare a migration documentation for the change() api, bindings and navigation. Thank you @jonataslaw

Thanks for trying to keep this great package up to date. We really appreciate your effort.

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! support getx forever!

getx is the best in flutter world! support getx forever!
Thank you so much for all you do.

I'm finally able to resolve this issue, thank you very much. https://github.com/jonataslaw/getx/discussions/2878

I'm finally able to resolve this issue, thank you very much. #2878

Please tell how you managed that.

you're rock bro

@jonataslaw you are the very good and intelligent programmer in the Flutter world I support getx forever ❤️ All the best @jonataslaw

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?

when will the new version be published?

Next year i guess

Hahaha It's almost ready to go, but I'm making sure it works perfectly in my projects in production. If it doesn't get any problems within 1-3 days, it will be pushed to pub.dev.

I'd rather be the guinea pig than push an update and you guys be mine, if something breaks I can fix it quickly.

Hahaha

It's almost ready to go, but I'm making sure it works perfectly in my projects in production. If it doesn't get any problems within 1-3 days, it will be pushed to pub.dev.

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 🥳

Hahaha It's almost ready to go, but I'm making sure it works perfectly in my projects in production. If it doesn't get any problems within 1-3 days, it will be pushed to pub.dev.

I'd rather be the guinea pig than push an update and you guys be mine, if something breaks I can fix it quickly.

Waiting for new challanges ✌️

Hahaha It's almost ready to go, but I'm making sure it works perfectly in my projects in production. If it doesn't get any problems within 1-3 days, it will be pushed to pub.dev.

I'd rather be the guinea pig than push an update and you guys be mine, if something breaks I can fix it quickly.

great

哈哈哈 它几乎准备好了，但我确保它在我的生产项目中完美运行。如果1-3天内没有出现任何问题，它将被推送到pub.dev。

我宁愿当小白鼠，也不愿推送更新，你们就是我的，如果出现问题我可以快速修复。

Excited for the update.

Hahaha It's almost ready to go, but I'm making sure it works perfectly in my projects in production. If it doesn't get any problems within 1-3 days, it will be pushed to pub.dev.

I'd rather be the guinea pig than push an update and you guys be mine, if something breaks I can fix it quickly.

Hahaha It's almost ready to go, but I'm making sure it works perfectly in my projects in production. If it doesn't get any problems within 1-3 days, it will be pushed to pub.dev.

I'd rather be the guinea pig than push an update and you guys be mine, if something breaks I can fix it quickly.

go go go

Hahaha It's almost ready to go, but I'm making sure it works perfectly in my projects in production. If it doesn't get any problems within 1-3 days, it will be pushed to pub.dev.

I'd rather be the guinea pig than push an update and you guys be mine, if something breaks I can fix it quickly.

the best news today

day after day~wait for you