GetX 5

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 c

Posted by jonataslaw on Aug 26, 2023, 9:32 PM

Tags

• github (Other)

Related issues

• struct's lifetime requirements can be bypassed via covariant field assignment
• Proposal to Reorganize the Moderation Team and Review Moderation Policies
• Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
• proposal: container/...: generic collection types
• Better Custom Endpoint BYOK
• A concrete policy for backward compatibility until Godot 5.0