4- Organize your project for real! Controllers must not be in your UI, place your TextEditController, or any controller you use within your Controller class.
I read the updated Readme again :-) Now I see the above statement, and makes me wondering how that would work?
Can you change the sample project to include a textinput handled by the controller (and hence using TextEditController inside a business class Controller)?
Thx.
So, with the new update, you should not insert controllers in your UI. I always found this approach very dirty, because if you have a registration application with 15 text fields, you would have to have 15 instances of TextEditingController in your UI, inside your StatefulWidget (wow, what an agony just to imagine it).
I think this approach is bad, and I created this package to completely decouple the UI from any type of logic, and to allow a greater readability of the UI that should have nothing but widgets and references to the controllers.
Doing it this way, you give total freedom to the Dev who is developing the logic, even to test it, since the controller is not in the View, and you give total freedom to the Dev who takes care of the UI to work, without a lot of code. controller that has nothing to do with his job.
class Controller extends GetController {
static Controller get to => Get.find();
/// Good practices:
/// *You can make your controllers private and access them via a get instead of making the variable
/// public.*
TextEditingController textCtl = TextEditingController();
List<String> messages;
void sendMessage() {
Api.sendMessage(textCtl.text);
addMessageToListView(textCtl.text);
textCtl.clear();
}
void addMessageToListView(String message) {
messages.add(message);
update(this);
}
}
On you view:
GetBuilder<Controller>(
init: Controller(),
builder: (_) => ListView.builder(
itemCount: _.messages.length,
itemBuilder: (context, index) {
return Bubble(_.messages[index]);
}),
),
Row(
children: [
TextField(
controller: Controller.to.textCtl,
),
FloatingActionButton(
mini: true,
onPressed: () {
Controller.to.sendMessage();
// if you don't like static alias, you can use: Get.find<Controller>().sendMessage();
})
],
)
Obviously, you can ignore all of this, as each person follows their design pattern, I often put my personal tastes in this lib, not least because it tops my biggest commercial project, but I also reiterate that controllers are Statefuls. Many people insert TextEditingController into the build method and with each view reconstruction, a new instance of it is created. In addition to bugs, memory leaks will happen. With this approach, it is in a controller where the state is managed by Get, and can be accessed even from another controller, imagine that the user is typing a comment in a post in a feed (like facebook, instagram, etc.), then he opens the post to see the better image, clicks to comment on that other screen, and the comment he started typing for that post, is there. This greatly improves user experience, and the important thing: It saves memory, it will not be 2 controllers in memory, only 1 (2 because the Flutter keeps the controller in memory until the screen is removed from the tree. If you navigate through 150 routes without the Get.off/pushReplacement on the screen that used the controller, it will be there).
I could write pages on how this approach improves code performance and readability, but I believe you鈥檝e got it.
When approaching testing, I believe I understand what you mean. I will analyze better how to produce tests with the Get instance manager.
Thanks @jonataslaw you do great job
Most helpful comment
So, with the new update, you should not insert controllers in your UI. I always found this approach very dirty, because if you have a registration application with 15 text fields, you would have to have 15 instances of TextEditingController in your UI, inside your StatefulWidget (wow, what an agony just to imagine it).
I think this approach is bad, and I created this package to completely decouple the UI from any type of logic, and to allow a greater readability of the UI that should have nothing but widgets and references to the controllers.
Doing it this way, you give total freedom to the Dev who is developing the logic, even to test it, since the controller is not in the View, and you give total freedom to the Dev who takes care of the UI to work, without a lot of code. controller that has nothing to do with his job.
On you view:
Obviously, you can ignore all of this, as each person follows their design pattern, I often put my personal tastes in this lib, not least because it tops my biggest commercial project, but I also reiterate that controllers are Statefuls. Many people insert TextEditingController into the build method and with each view reconstruction, a new instance of it is created. In addition to bugs, memory leaks will happen. With this approach, it is in a controller where the state is managed by Get, and can be accessed even from another controller, imagine that the user is typing a comment in a post in a feed (like facebook, instagram, etc.), then he opens the post to see the better image, clicks to comment on that other screen, and the comment he started typing for that post, is there. This greatly improves user experience, and the important thing: It saves memory, it will not be 2 controllers in memory, only 1 (2 because the Flutter keeps the controller in memory until the screen is removed from the tree. If you navigate through 150 routes without the Get.off/pushReplacement on the screen that used the controller, it will be there).
I could write pages on how this approach improves code performance and readability, but I believe you鈥檝e got it.
When approaching testing, I believe I understand what you mean. I will analyze better how to produce tests with the Get instance manager.