I need your opinion.

[jonataslaw]

I'm working on version 3.0 of Get, and I need your opinion on some topics.

1. I have received countless issues and messages asking to change the lib name, as "Get" is the most common word in English, which makes the search IMPOSSIBLE. I even run into questions on StackOverflow by chance, because it is impossible to find something through research. I thought of "GetX" to not have to create another repository, another package in the pub and etc. I could take advantage of Get, and just name the Package name as GetX. If someone has a better suggestion, speak up, or say if you agree with that.

2. Get will now become a framework (no longer micro), will have its own CLI, its extensions for VsCode / Intellij, and soon a unique solution that will be launched as soon as it is patented (it will be open source, but the idea needs to be protected). We will add internationalization (translation package), Storage (storage of key / value as sharedPreferences, but synchronous), and a Wrapper for ApiREST / Websockets. Get will start working with abstractions, and anyone will be able to extend GetInterface and create micropackages for Get, including you who are reading. Anything you find useful in your day to day, you can integrate this package. All micropackages will be inserted in the readme, and those that do not add size to the lib, or that have a greater number of downloads will be integrated into the core.

3. I really need opinions on this: Get is currently doing the AOT compilation division. Even though everything seems to be centralized, if you don't use routes, for example, nothing of routes is compiled in the application, only what was used from Get is actually compiled. However, some things like Storage, will require plugins like "path", which will identify the file folder to write to it. What should I do about it?

a: Create the get-core with as few dependencies as possible, without storage, internationalization, only with injection of routes, dependencies and status and add these features to Get main.

b: Create a "get-full" with all features, and leave this package as is.

c: try to create micropackages based on abstraction, and add them by extensions, and the integration settings must be done manually.

I appreciate any comments.

[Nipodemos]

1. i agree with the name GetX, it is very good. On a later moment, maybe it would be a good thing to change the widget name GetX? i guess this can confuse people.

2. i don't have to knowledge to comment about that.

3. hum... i like the ideia of using only one package to get everything i will need, so separate everything may be not a good idea.If you create a Get-full with the features of this package plus what you said, and still leave this here, i think it would be very confusing! I mean, someone with little knowledge will see those 2 packages and ask which one should they use. Unless you make a good documentation about the differences and equalities, this can turn into hundreds of issues. I guess the third option will be better, make this get the main one with everything that doesn't add size, and link to other micropackages if people want other things. But always considering this package as the major one and putting everything that is possible

[fabio-santana]

1. GetX;
2. It's a good idea!!
3. b (full);

Congratz and Good luck man!

[AKushWarrior]

1. GetX

2. I like this.

3. I think 1 (core+ add-ons) makes the most sense to minimize compiled size.

[barriehadfield]

1. GetX (though searching will still be hard, so what will matter more is having people know about the framework and blogging and writing about it, comparing it to other well-known methods (Bloc, , Redux, etc). This is essential in building up credibility.

RE licensing point, please choose very carefully and avoid copyleft or anything that an IP lawyer will flag in DD. Good CTO's are hyper-sensitive in VC/PE backed or aspirant companies.

RE framework vs micro-framework (packaging) - you will need to think carefully about your positioning with other Frameworks (you never want users confused about if it Getx vs Flutter or anything). For many years, I have been one of the contributors to https://hyperstack.org/ , which is a Ruby framework with works alongside Rails and we have struggled a lot with positioning. In retrospect, it would have been better to describe our system as a set of architectural constructs that the user can choose to add to their project vs. one framework with many parts. Perhaps one way to come to the right idea here is to think about how the documentation is structured and work backwards from that. There needs to be conceptual clarity for a newcomer.

One a final point - community matters. At the moment the only communication tool are these Github issues and that just feels wrong to ask questions - feels like you are raising. a bug when actually you are just asking a question. Have you considered a free Slack project? When it works well you will have people 24/7 helping each other.

Its a delight to have discovered your project and I think that what you are doing is incredible and I am very privileged to know of it in its early days. Hope this response is helpful. Please say if you need any help - Slack, documentation, etc.

[Nipodemos]

Slack is acually a nice idea i wanted discord, but i know it is not so professional as slack, so the first choice is better @barriehadfield there is a gitter chat for this package, but almost no one uses gitter

[loicgeek]

@jonataslaw hi, Re 1. Indeed , the name "Get" is too short and is hardly completed by vs code, so if the next update will be a big update, even GetX is short, choose something more longer. Re 2 . I don't know how you have implemented an internationalization feature, but I saw your example where you used Text("hello".fr), I think that it has throwbacks,

-No autocomplete: using as it vs code could not provide auto-complete, We could rather use JSON file , and something like Text(trans("common.settings")) where we have a JSON file { "common":{ "settings":"Parametres" } }, you can check how I have implemented that here https://github.com/loicgeek/flutter_localization_boilerplate, I have also developed a VSCode plugin provide autocomplete feature for such JSON files here https://marketplace.visualstudio.com/items?itemName=loicgeek.json-completer, you just have to specify functions that you use to translate text, and the path to your 'model' file.

[fer-ri]

1. GetX :+1:
2. :+1:
3. Choose opt 1, core only with features like now, because sometimes we don't need the other ones.

[azliabdullah]

1. The name definitely need to change. get is too common. And it can be confused with getter or getMethodName. I'm not so keen on GetX because still sounds generic. Suggest to find a creative and quite unique like the folks of bloc, redux, mobx.
2. 100% agree. If you don't mind make the framework opinionated too.
3. option A. Core should be DI, state management, routes injection. Other can be add-ons or packages. Just like Spring Boot does.

[duck-dev-go]

1. GetX;
2. Yes I agree
3. c (the micro packages should be easy to implement)

[rrousselGit]

As a side-note:

Get is currently doing the AOT compilation division. Even though everything seems to be centralized, if you don't use routes, for example, nothing of routes is compiled in the application, only what was used from Get is actually compiled

It's not that easy. Some things will get stripped out for sure. But not everything.

The reason behind it is because GetMaterialApp still references a bunch of these objects, so even if unused, they'll still be shipped with the app.

One easy test for that is to inspect what's on memory in a --profile app, and you'll see a few get-specific navigation objects.

[jonataslaw]

As a side-note:

Get is currently doing the AOT compilation division. Even though everything seems to be centralized, if you don't use routes, for example, nothing of routes is compiled in the application, only what was used from Get is actually compiled

It's not that easy. Some things will get stripped out for sure. But not everything.

The reason behind it is because GetMaterialApp still references a bunch of these objects, so even if unused, they'll still be shipped with the app.

One easy test for that is to inspect what's on memory in a --profile app, and you'll see a few get-specific navigation objects.

GetMaterialApp is only used when routes are used. If only state manager is used, it is not necessary. So only if the person is going to use routes he will have these files related to routes, since he will use MaterialApp instead of GetMaterialApp, and in the state manager there is no reference or import to the methods or variables of the route manager. Obviously if someone does not use routes and uses GetMaterialApp, it will have more things in memory than it deferred, because some instances are started internally, but this does not happen if they just use the dependency / state manager.

[denimobs]

1 -> GetX is a good name. 2-> all these new stuff will be amazing. 3 -> c, I like the idea of choosing what I will use

[stefandevo]

As the most the name is too common. So GetX would be a better name.

I really think you should be able to have all parts seperate. As I like the routing, DI, state management and I using my own solution for API's or storage. So it would be great if these are not mandatory in the package and arre plugins for the system. So abstractions would be great, but make them optional. Also add an abstraction for your (debug)logging so that we can use our own logging library and thereby include the logging of GetX. So only include whats is really necessary for the current package.

Also I think a Slack would be a better and more common thing than Gitter or Discord. I saw you now have Discord too; I don't like to look at 3 places to find more info on the library. I understand that Github issues are for issues and not questions. So there needs to be a special place for questions an answers.
This could be Slack (as this is the most used) or something like Discourse which would be the best fit for questions and answers as this is a forum. Documentation could be in an other platform as well. (GitBook)

[murilosandiego]

1. GetiveX 😂😂😂
2. Yes
3. c

[RodBr]

1. Googling "flutter getx" returns the get package first in the list, so it's a nice clean name, only confusion may be with points (getx, gety) but with flutter in the search term it works fine.
2. Sounds very interesting, yes
3. The package docs are already getting large, so I think splitting things up (c) would be more futureproof

[esDotDev]

1, GetX sounds great

2. Sounds like it is on the path to get bloated. I really think you're at a great place right now in terms of learning curve and complexity. Does localization, preferences and all that really have anything to do with GetIt's current focus og "High performance state management, intelligent dependency injection, and route management"? Seems like that is already a lot for one package. Why not stop there, and just make these additional features as separate standalone packages? GetX-Localization, GetX-Prefs, etc?
3. Flutter apps are already fairly lightweight, I don't think the inclusion of a few code-only deps is a big issue. Would prefer no-hassle setup.

[Nipodemos]

so many different opinions 🤯 is impressive how each person can differ so much in their choices and all have very good points to defend their opinion, i like that

that will be a tough decision for @jonataslaw to make 😅

[lotus-x]

1. Even there is another good name, everyone still know this package as get. So go with GetX. I like when people add X to name 😉🤣
2. Yeah good idea
3. I like those as micro packages. Anyone can add only what they want..

Its nice to see such a good package with good community ❤

[jlubeck]

Another vote for Slack!

Some of my issues in the past could definitely have been asnwered on slack instead of an issue.

[ghenry]

Something Google search will pick up. S.O. #getx and google groups.

GetX :-)

[raphapc]

1. GetX seems good but maybe is still too generic
2. I'm afraid it may lose focus, but can be interesting.
3. c

[jonataslaw]

Thanks to everyone who participated