Getx: Is GetConnect Needed??

[eldadj]

I like how GetX was focused on helping to ease navigation and data/state management of Flutter Apps. It removed the need to decide/worry so much about which M(V/P/T)(C/P) to use.

Introduction of GetService also helped in ensuring that the above was even easier.

The introduction of the GetConnect, in my opinion, is taking GetX in a different direction. Flutter/Dart already has http/Dio, which work very very well.

• Is there a rationale for adding GetConnect?
• Won't it take away energy and resources from maintaining and working on the core GetX?
• Most people who use GetX have already settled on long time established alternatives. I understand that for state management, there are alternatives, but GetX makes it just too easy and flexible to even think about the alternatives.
• I also know that the team behind GetX WILL be able to do something awesome at the end of the day with GetConnect, but is it critical right now?

Please don't get me wrong, just need some insights.

Thanks for GetX!!!

[jonataslaw]

Not to be repetitive, here's why I decided to create GetConnect.
https://github.com/jonataslaw/getx/issues/797

Well, complementing what I had already said, in addition to http/sockets being something very common that is present in almost every type of application, I see that:
1- http requests and sockets still have a small level of complexity which we intend to facilitate. GetConnect is still a kid, and is getting a lot of updates, but it will be a very useful feature for most applications.
2- We intend to build a solid base of examples. These examples will include http communication and sockets, because they are common. The big problem I currently see with this is the same as the tutorials on GetX + dio or Getx + http on youtube, if the video uses http, there will be dozens of comments asking you to do with the dio. If the tutorial uses dio, there will be hundreds of users asking to do it with http. GetX snippets had to implement snippets for http and snippets for audio. You see, this shouldn't be necessary, but because it has different ways of working, it always doubles our work.
3- In addition to snippets, another point we consider is our integration with the CLI. Thanks to GetConnect, Cristiano (CLI's main collaborator) managed to make a resource that was 6 months away. Today it is possible with a command, create all the necessary boilerplate for your api rest, and in the next update, defining the url it will configure the Endpoint, download the json response, create the Model and integrate the model automatically. This means HOURS of automated work. How would we do that? would we add an external package when the user created the provider in the CLI? We would have to create templates for dio and http. What if Dio or http updated? We would have to change our CLI. GetX has no external dependencies, because this fully guarantees that nothing external can break the project. We know what an update (in the package) can impact on the CLI, so if we update the package, we update the cli, we update the pro vscode extension, we update the pro android studio extension. I can sleep peacefully making sure that my projects using GetX will not break or become incompatible if tomorrow the http.get (String url) method changes to http.get (Uri uri).
I agree that this requires a lot of human resources, but the most difficult has already been done. I spent about 72 hours to create GetConnect and all its features, but he has already received 2 PRs that have been improved by another contributor. Fortunately today the GetX community is huge, and it spans all continents (you can see by the number of readme translations and how many people are engaged in updating it), so today I create resources without fear of not having time to maintain the resource, simply because the community maintains it.
Ahh, and there is no difference if you already use http or dio. If you don't use GetConnect, not a single line of it will be compiled in your application.
Another thing I'm thinking about is to create a Mixin to automate the loading, errors and requests of GetConnect (like StateMixin), so you will only have to type in the url and method, and the whole page happens.
Finally, the goal of GetX is also to have everything ready. I didn't feel ready before an http method, because 100% of my projects depend on it. In addition, sockets and http match GetServer perfectly, sending events and listening to them is as easy as declaring a class, and that makes working with the ecosystem pleasant.
Well, I think that's it.

[eldadj]

What a response. 👏 👏

1. I feel so dumb for not reading/checking to see if you had said your reasons for setting up GetConnect.
2. Your point (2) above is very appropriate. We, users, can always demand for everything and anything. Since we have wonderful people like you, we become soooo lazy and like all our tools to work as one cohesive unit.
3. The only issue why I even raised this issue, is that when using Dio and GetX in the same dart file, it complains about Response being redefined, and I didn't know which of them (dio or getx) to alias the import. (I was just being lazy, really).

That not withstanding, GetX is a wonderful project and its always the 1st thing I add to my pubspec.yaml.
For this well articulated response, I will migrate to GetConnect and hope to contribute to it.

Thanks for a great project.