Created a State Managers main section

Nipodemos
Commit 44ab21761b277423011de3892c0b3fd3fcd83024 44ab2176 1 parent 79b962b6
Showing 1 changed file with 304 additions and 254 deletions
README.md
--- a/README.md
View file @44ab217
+++ b/README.md
View file @44ab217
@@ -55,22 +55,35 @@ class Other extends StatelessWidget {
 This is a simple project but it already makes clear how powerful Get is. As your project grows, this difference will become more significant. Get was designed to work with teams, but it makes the job of an individual developer simple. Improve your deadlines, deliver everything on time without losing performance. Get is not for everyone, but if you identified with that phrase, Get is for you!
-- [How to use?](#how-to-use)
-- [Navigating without named routes](#navigating-without-named-routes)
+- [State Management](#state-management)
+  - [Simple State Manager](#simple-state-manager)
+    - [Advantages of using it](#advantages-of-using-it)
+    - [Simple state manager usage](#simple-state-manager-usage)
+    - [How it handles controllers](#how-it-handles-controllers)
+    - [You won't need StatefulWidgts anymore](#you-wont-need-statefulwidgts-anymore)
+    - [Why it exists](#why-it-exists)
+    - [Other ways of using it](#other-ways-of-using-it)
+    - [Unique IDs](#unique-ids)
+  - [Reactive State Manager](#reactive-state-manager)
+    - [Advantages](#advantages)
+    - [Usage:](#usage)
+    - [Where .obs can be used](#where-obs-can-be-used)
+    - [Note about Lists](#note-about-lists)
+    - [Why i have to use .value?](#why-i-have-to-use-value)
+    - [Obx()](#obx)
+  - [Mixing the two state managers](#mixing-the-two-state-managers)
+  - [GetX vs GetBuilder vs Obx vs MixinBuilder](#getx-vs-getbuilder-vs-obx-vs-mixinbuilder)
+- [Dependency Management](#dependency-management)
+  - [How to use?](#how-to-use)
+  - [Navigating without named routes](#navigating-without-named-routes)
     - [SnackBars](#snackbars)
     - [Dialogs](#dialogs)
     - [BottomSheets](#bottomsheets)
-- [Simple State Manager](#simple-state-manager)
-  - [Simple state manager usage](#simple-state-manager-usage)
-    - [No StatefulWidget:](#no-statefulwidget)
-      - [Forms of use:](#forms-of-use)
-- [Reactive State Manager](#reactive-state-manager)
-  - [GetX vs GetBuilder vs Obx vs MixinBuilder](#getx-vs-getbuilder-vs-obx-vs-mixinbuilder)
-- [Simple Instance Manager](#simple-instance-manager)
-- [Bindings](#bindings)
+  - [Simple Instance Manager](#simple-instance-manager)
+  - [Bindings](#bindings)
       - [To use this API you only need:](#to-use-this-api-you-only-need)
-- [Workers:](#workers)
-- [Navigate with named routes:](#navigate-with-named-routes)
+  - [Workers:](#workers)
+  - [Navigate with named routes:](#navigate-with-named-routes)
     - [Send data to named Routes:](#send-data-to-named-routes)
       - [Dynamic urls links](#dynamic-urls-links)
       - [Middleware](#middleware)
@@ -87,251 +100,41 @@ This is a simple project but it already makes clear how powerful Get is. As your
 - Offering PRs for code/tests.
 - Including new functions.
-Any contribution is welcome!
-
-## How to use?
-
-<!-- - Flutter Master/Dev/Beta: version 2.0.x-dev 
-- Flutter Stable branch: version 2.0.x
-(look for latest version on pub.dev) -->
-
-Add this to your pubspec.yaml file:
-
-```
-dependencies:
-  get: 
-```
-If you are going to use routes/snackbars/dialogs/bottomsheets without context, or use the high-level Get APIs, you need to simply add "Get" before your MaterialApp, turning it into GetMaterialApp and enjoy!
-
-```dart
-GetMaterialApp( // Before: MaterialApp(
-  home: MyHome(),
-)
-```
-## Navigating without named routes
-To navigate to a new screen:
-
-```dart
-Get.to(NextScreen());
-```
-
-To close snackbars, dialogs, bottomsheets, or anything you would normally close with Navigator.pop(context);
-
-```dart
-Get.back();
-```
-
-To go to the next screen and no option to go back to the previous screen (for use in SplashScreens, login screens and etc.)
-
-```dart
-Get.off(NextScreen());
-```
-
-To go to the next screen and cancel all previous routes (useful in shopping carts, polls, and tests)
-
-```dart
-Get.offAll(NextScreen());
-```
-
-To navigate to the next route, and receive or update data as soon as you return from it:
-```dart
-var data = await Get.to(Payment());
-```
-on other screen, send a data for previous route:
-
-```dart
-Get.back(result: 'success');
-```
-And use it:
-
-ex:
-```dart
-if(data == 'success') madeAnything();
-```
-Don't you want to learn our syntax?
-Just change the Navigator (uppercase) to navigator (lowercase), and you will have all the functions of the standard navigation, without having to use context
-Example:
-
-```dart
+# State Management
+There are currently several state managers for Flutter. However, most of them involve using ChangeNotifier to update widgets and this is a bad and very bad approach to performance of medium or large applications. You can check in the official Flutter documentation that ChangeNotifier should be used with 1 or a maximum of 2 listeners (https://api.flutter.dev/flutter/foundation/ChangeNotifier-class.html), making it practically unusable for any application medium or large. 
-// Default Flutter navigator
-Navigator.of(context).push(
-  context,
-  MaterialPageRoute(
-    builder: (BuildContext context) { 
-      return HomePage();
-    },
-  ),
-);
+Other state managers are good, but have their nuances:
+- BLoC is very safe and efficient, but it is very complex for beginners, which has kept people from developing with Flutter.
+- MobX is easier than BLoC and reactive, almost perfect, I would say, but you need to use a code generator, that for large applications, reduces productivity, since you will need to drink a lot of coffees until your code is ready again after a `flutter clean` (And this is not MobX's fault, but the codegen which is really slow!).
+- Provider uses InheritedWidget to deliver the same listener, as a way of solving the problem reported above with ChangeNotifier, which implies that any access to its ChangeNotifier class must be within the widget tree because of the context to access o Inherited.
-// Get using Flutter syntax without needing context
-navigator.push(
-  MaterialPageRoute(
-    builder: (_) { 
-      return HomePage();
-    },
-  ),
-);
-
-// Get syntax (It is much better, but you have the right to disagree)
-Get.to(HomePage());
-
-
-```
-
-### SnackBars
-
-To have a simple SnackBar with Flutter, you must get the context of Scaffold, or you must use a GlobalKey attached to your Scaffold, 
-```dart
-final snackBar = SnackBar(
-  content: Text('Hi!'),
-  action: SnackBarAction(
-    label: 'I am a old and ugly snackbar :(',
-    onPressed: (){}
-  ),
-);
-// Find the Scaffold in the widget tree and use
-// it to show a SnackBar.
-Scaffold.of(context).showSnackBar(snackBar);
-```
-
-With Get:
-
-```dart
-Get.snackbar('Hi', 'i am a modern snackbar');
-```
-
-With Get, all you have to do is call your Get.snackbar from anywhere in your code or customize it however you want!
-
-```dart
-Get.snackbar(
-  "Hey i'm a Get SnackBar!", // title
-  "It's unbelievable! I'm using SnackBar without context, without boilerplate, without Scaffold, it is something truly amazing!", // message
-  icon: Icon(Icons.alarm), 
-  shouldIconPulse: true,
-  onTap:(){},
-  barBlur: 20,
-  isDismissible: true,
-  duration: Duration(seconds: 3),
-);
-
-
-  ////////// ALL FEATURES //////////
-  //     Color colorText,
-  //     Duration duration,
-  //     SnackPosition snackPosition,
-  //     Widget titleText,
-  //     Widget messageText,
-  //     bool instantInit,
-  //     Widget icon,
-  //     bool shouldIconPulse,
-  //     double maxWidth,
-  //     EdgeInsets margin,
-  //     EdgeInsets padding,
-  //     double borderRadius,
-  //     Color borderColor,
-  //     double borderWidth,
-  //     Color backgroundColor,
-  //     Color leftBarIndicatorColor,
-  //     List<BoxShadow> boxShadows,
-  //     Gradient backgroundGradient,
-  //     FlatButton mainButton,
-  //     OnTap onTap,
-  //     bool isDismissible,
-  //     bool showProgressIndicator,
-  //     AnimationController progressIndicatorController,
-  //     Color progressIndicatorBackgroundColor,
-  //     Animation<Color> progressIndicatorValueColor,
-  //     SnackStyle snackStyle,
-  //     Curve forwardAnimationCurve,
-  //     Curve reverseAnimationCurve,
-  //     Duration animationDuration,
-  //     double barBlur,
-  //     double overlayBlur,
-  //     Color overlayColor,
-  //     Form userInputForm
-  ///////////////////////////////////
-```
-If you prefer the traditional snackbar, or want to customize it from scratch, including adding just one line (Get.snackbar makes use of a mandatory title and message), you can use 
-`Get.rawSnackbar();` which provides the RAW API on which Get.snackbar was built.
-
-### Dialogs
-
-To open dialog:
-
-```dart
-Get.dialog(YourDialogWidget());
-```
-
-To open default dialog:
-
-```dart
-Get.defaultDialog(
-  onConfirm: () => print("Ok"),
-  middleText: "Dialog made in 3 lines of code"
-);
-```
-You can also use Get.generalDialog instead of showGeneralDialog.
-
-For all other Flutter dialog widgets, including cupertinos, you can use Get.overlayContext instead of context, and open it anywhere in your code.
-For widgets that don't use Overlay, you can use Get.context.
-These two contexts will work in 99% of cases to replace the context of your UI, except for cases where inheritedWidget is used without a navigation context.
-
-### BottomSheets
-Get.bottomSheet is like showModalBottomSheet, but don't need of context.
-
-```dart
-Get.bottomSheet(
-  Container(
-    child: Wrap(
-      children: <Widget>[
-        ListTile(
-          leading: Icon(Icons.music_note),
-          title: Text('Music'),
-          onTap: () => {}
-        ),
-        ListTile(
-          leading: Icon(Icons.videocam),
-          title: Text('Video'),
-          onTap: () => {},
-        ),
-      ],
-    ),
-  );
-);
-```
-
-## Simple State Manager
-There are currently several state managers for Flutter. However, most of them involve using ChangeNotifier to update widgets and this is a bad and very bad approach to performance of medium or large applications. You can check in the official Flutter documentation that ChangeNotifier should be used with 1 or a maximum of 2 listeners (https://api.flutter.dev/flutter/foundation/ChangeNotifier-class.html), making it practically unusable for any application medium or large. Other state managers are good, but have their nuances. BLoC is very safe and efficient, but it is very complex for beginners, which has kept people from developing with Flutter. MobX is easier than BLoC and reactive, almost perfect, I would say, but you need to use a code generator that for large applications, reduces productivity, you will need to drink a lot of coffees until your code is ready again after a Flutter clean (And this is not MobX's fault, but the codegen which is really slow!). Provider uses InheritedWidget to deliver the same listener, as a way of solving the problem reported above with ChangeNotifier, which implies that any access to its ChangeNotifier class must be within the widget tree because of the context to access o Inherited.
 Get isn't better or worse than any other state manager, but that you should analyze these points as well as the points below to choose between using Get in pure form (Vanilla), or using it in conjunction with another state manager. Definitely, Get is not the enemy of any other state manager, because Get is a microframework, not just a state manager, and can be used either alone or in conjunction with them.
-Get has a state manager that is extremely light and easy (written in just 95 lines of code), which does not use ChangeNotifier, will meet the need especially for those new to Flutter, and will not cause problems for large applications.
-
-What performance improvements does Get bring?
+## Simple State Manager
-1- Update only the required widget.
+Get has a state manager that is extremely light and easy, which does not use ChangeNotifier, will meet the need especially for those new to Flutter, and will not cause problems for large applications.
-2- Does not use changeNotifier, it is the state manager that uses less memory (close to 0mb for until).
+### Advantages of using it
-3- Forget StatefulWidget! With Get you will never need it. With the other state managers, you will probably have to use a StatefulWidget to get the instance of your Provider, BLoC, MobX Controller, etc. But have you ever stopped to think that your appBar, your scaffold, and most of the widgets that are in your class are stateless? So why save the state of an entire class, if you can only save the state of the Widget that is stateful? Get solves that, too. Create a Stateless class, make everything stateless. If you need to update a single component, wrap it with GetBuilder, and its state will be maintained.
+1. Update only the required widgets.
-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.
+2. Does not use changeNotifier, it is the state manager that uses less memory (close to 0mb).
-5- Do you need to trigger an event to update a widget as soon as it is rendered? GetBuilder has the property "initState", just like StatefulWidget, and you can call events from your controller, directly from it, no more events being placed in your initState.
+3. Forget StatefulWidget! With Get you will never need it. With the other state managers, you will probably have to use a StatefulWidget to get the instance of your Provider, BLoC, MobX Controller, etc. But have you ever stopped to think that your appBar, your scaffold, and most of the widgets that are in your class are stateless? So why save the state of an entire class, if you can only save the state of the Widget that is stateful? Get solves that, too. Create a Stateless class, make everything stateless. If you need to update a single component, wrap it with GetBuilder, and its state will be maintained.
-6- Do you need to trigger an action like closing streams, timers and etc? GetBuilder also has the dispose property, where you can call events as soon as that widget is destroyed.
+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.
-7- Use streams only if necessary. You can use your StreamControllers inside your controller normally, and use StreamBuilder also normally, but remember, a stream reasonably consumes memory, reactive programming is beautiful, but you shouldn't abuse it. 30 streams open simultaneously can be worse than changeNotifier (and changeNotifier is very bad).
+5. Do you need to trigger an event to update a widget as soon as it is rendered? GetBuilder has the property "initState", just like StatefulWidget, and you can call events from your controller, directly from it, no more events being placed in your initState.
-8- Update widgets without spending ram for that. Get stores only the GetBuilder creator ID, and updates that GetBuilder when necessary. The memory consumption of the get ID storage in memory is very low even for thousands of GetBuilders. When you create a new GetBuilder, you are actually sharing the state of GetBuilder that has a creator ID. A new state is not created for each GetBuilder, which saves A LOT OF ram for large applications. Basically your application will be entirely Stateless, and the few Widgets that will be Stateful (within GetBuilder) will have a single state, and therefore updating one will update them all. The state is just one.
+6. Do you need to trigger an action like closing streams, timers and etc? GetBuilder also has the dispose property, where you can call events as soon as that widget is destroyed.
-9- Get is omniscient and in most cases it knows exactly the time to take a controller out of memory. You should not worry about when to dispose of a controller, Get knows the best time to do this. Example:
+7. Use streams only if necessary. You can use your StreamControllers inside your controller normally, and use StreamBuilder also normally, but remember, a stream reasonably consumes memory, reactive programming is beautiful, but you shouldn't abuse it. 30 streams open simultaneously can be worse than changeNotifier (and changeNotifier is very bad).
-- Class a => Class B (has controller X) => Class C (has controller X)
+8. Update widgets without spending ram for that. Get stores only the GetBuilder creator ID, and updates that GetBuilder when necessary. The memory consumption of the get ID storage in memory is very low even for thousands of GetBuilders. When you create a new GetBuilder, you are actually sharing the state of GetBuilder that has a creator ID. A new state is not created for each GetBuilder, which saves A LOT OF ram for large applications. Basically your application will be entirely Stateless, and the few Widgets that will be Stateful (within GetBuilder) will have a single state, and therefore updating one will update them all. The state is just one.
-In class A the controller is not yet in memory, because you have not used it yet (Get is lazyLoad). In class B you used the controller, and it entered memory. In class C you used the same controller as in class B, Get will share the state of controller B with controller C, and the same controller is still in memory. If you close screen C and screen B, Get will automatically take controller X out of memory and free up resources, because Class a is not using the controller. If you navigate to B again, controller X will enter memory again, if instead of going to class C, you return to class A again, Get will take the controller out of memory in the same way. If class C didn't use the controller, and you took class B out of memory, no class would be using controller X and likewise it would be disposed of. The only exception that can mess with Get, is if you remove B from the route unexpectedly, and try to use the controller in C. In this case, the creator ID of the controller that was in B was deleted, and Get was programmed to remove it from memory every controller that has no creator ID. If you intend to do this, add the "autoRemove: false" flag to class B's GetBuilder and use adoptID = true; in class C's GetBuilder.
+9. Get is omniscient and in most cases it knows exactly the time to take a controller out of memory. You should not worry about when to dispose of a controller, Get knows the best time to do this.
 ### Simple state manager usage
@@ -404,7 +207,14 @@ FloatingActionButton(
 ```
 When you press FloatingActionButton, all widgets that are listening to the 'counter' variable will be updated automatically.
-#### No StatefulWidget:
+### How it handles controllers
+Let's say we have this:
+
+`Class a => Class B (has controller X) => Class C (has controller X)`
+
+In class A the controller is not yet in memory, because you have not used it yet (Get is lazyLoad). In class B you used the controller, and it entered memory. In class C you used the same controller as in class B, Get will share the state of controller B with controller C, and the same controller is still in memory. If you close screen C and screen B, Get will automatically take controller X out of memory and free up resources, because Class a is not using the controller. If you navigate to B again, controller X will enter memory again, if instead of going to class C, you return to class A again, Get will take the controller out of memory in the same way. If class C didn't use the controller, and you took class B out of memory, no class would be using controller X and likewise it would be disposed of. The only exception that can mess with Get, is if you remove B from the route unexpectedly, and try to use the controller in C. In this case, the creator ID of the controller that was in B was deleted, and Get was programmed to remove it from memory every controller that has no creator ID. If you intend to do this, add the "autoRemove: false" flag to class B's GetBuilder and use adoptID = true; in class C's GetBuilder.
+
+### You won't need StatefulWidgts anymore
 Using StatefulWidgets means storing the state of entire screens unnecessarily, even because if you need to minimally rebuild a widget, you will embed it in a Consumer/Observer/BlocProvider/GetBuilder/GetX/Obx, which will be another StatefulWidget.
 The StatefulWidget class is a class larger than StatelessWidget, which will allocate more RAM, and this may not make a significant difference between one or two classes, but it will most certainly do when you have 100 of them!
 Unless you need to use a mixin, like TickerProviderStateMixin, it will be totally unnecessary to use a StatefulWidget with Get. 
@@ -431,6 +241,8 @@ void onInit() {
 ```
 - NOTE: If you want to start a method at the moment the controller is called for the first time, you DON'T NEED to use constructors for this, in fact, using a performance-oriented package like Get, this borders on bad practice, because it deviates from the logic in which the controllers are created or allocated (if you create an instance of this controller, the constructor will be called immediately, you will be populating a controller before it is even used, you are allocating memory without it being in use, this definitely hurts the principles of this library). The onInit() methods; and onClose(); were created for this, they will be called when the Controller is created, or used for the first time, depending on whether you are using Get.lazyPut or not. If you want, for example, to make a call to your API to populate data, you can forget about the old-fashioned method of initState/dispose, just start your call to the api in onInit, and if you need to execute any command like closing streams, use the onClose() for that.
+
+### Why it exists
 The purpose of this package is precisely to give you a complete solution for navigation of routes, management of dependencies and states, using the least possible dependencies, with a high degree of decoupling. Get engages all high and low level Flutter APIs within itself, to ensure that you work with the least possible coupling. We centralize everything in a single package, to ensure that you don't have any kind of coupling in your project. That way, you can put only widgets in your view, and leave the part of your team that works with the business logic free, to work with the business logic without depending on any element of the View. This provides a much cleaner working environment, so that part of your team works only with widgets, without worrying about sending data to your controller, and part of your team works only with the business logic in its breadth, without depending on no element of the view.
 So to simplify this:
@@ -458,7 +270,7 @@ Controller life cycle:
 - onClose() where it is closed to make any changes in preparation for the delete method
 - deleted: you do not have access to this API because it is literally removing the controller from memory. It is literally deleted, without leaving any trace.
-##### Forms of use:
+### Other ways of using it
 You can use Controller instance directly on GetBuilder value:
@@ -513,9 +325,8 @@ GetBuilder<Controller>(
 ),
 ```
-<!-- This approach is not recommended, as you will have to manually dispose of your controllers, close your streams manually, and literally give up one of the great benefits of this library, which is intelligent memory control. But if you trust your potential, go ahead! -->
-
+### Unique IDs
 If you want to refine a widget's update control with GetBuilder, you can assign them unique IDs:
 ```dart
 GetBuilder<Controller>( 
@@ -537,22 +348,25 @@ update(['text'], counter < 10);
 ```
 GetX does this automatically and only reconstructs the widget that uses the exact variable that was changed, if you change a variable to the same as the previous one and that does not imply a change of state , GetX will not rebuild the widget to save memory and CPU cycles (3 is being displayed on the screen, and you change the variable to 3 again. In most state managers, this will cause a new rebuild, but with GetX the widget will only is rebuilt again, if in fact his state has changed).
+
+## Reactive State Manager
+
+### Advantages
 GetBuilder is aimed precisely at multiple state control. Imagine that you added 30 products to a cart, you click delete one, at the same time that the list is updated, the price is updated and the badge in the shopping cart is updated to a smaller number. This type of approach makes GetBuilder killer, because it groups states and changes them all at once without any "computational logic" for that. GetBuilder was created with this type of situation in mind, since for ephemeral change of state, you can use setState and you would not need a state manager for this. However, there are situations where you want only the widget where a certain variable has been changed to be rebuilt, and this is what GetX does with a mastery never seen before.
 That way, if you want an individual controller, you can assign IDs for that, or use GetX. This is up to you, remembering that the more "individual" widgets you have, the more the performance of GetX will stand out, while the performance of GetBuilder should be superior, when there is multiple change of state.
-You can use both in any situation, but if you want to tune their application to the maximum possible performance, I would say that: if your variables are changed at different times, use GetX, because there is no competition for it when the subject is to rebuild only what is necessary, if you do not need unique IDs, because all your variables will be changed when you perform an action, use GetBuilder, because it is a simple state updater in blocks, made in a few lines of code, to make just what he promises to do: update state in blocks. There is no way to compare RAM, CPU, or anything else from a giant state manager to a simple StatefulWidget (like GetBuilder) that is updated when you call update(this). It was done in a simple way, to have the least computational logic involved, just to fulfill a single purpose and spend the minimum resources possible for that purpose.
+You can use both in any situation, but if you want to tune their application to the maximum possible performance, I would say that: if your variables are changed at different times, use GetX, because there is no competition for it when the subject is to rebuild only what is necessary, if you do not need unique IDs, because all your variables will be changed when you perform an action, use GetBuilder, because it is a simple state updater in blocks, made in a few lines of code, to make just what he promises to do: update state in blocks. There is no way to compare RAM, CPU, or anything else from a giant state manager to a simple StatefulWidget (like GetBuilder) that is updated when you call update(). It was done in a simple way, to have the least computational logic involved, just to fulfill a single purpose and spend the minimum resources possible for that purpose.
 If you want a powerful state manager, you can go without fear to GetX. It does not work with variables, but flows, everything in it is streams under the hood. You can use rxDart in conjunction with it, because everything is stream, you can hear the event of each "variable", because everything in it is stream, it is literally BLoC, easier than MobX, and without code generator or decorations .
-
-## Reactive State Manager 
-
 If you want power, Get gives you the most advanced state manager you could ever have.
 GetX was built 100% based on Streams, and give you all the firepower that BLoC gave you, with an easier facility than using MobX.
 Without decorations, you can turn anything into Observable with just a ".obs".
 Maximum performance: In addition to having a smart algorithm for minimal reconstruction, Get uses comparators to make sure the state has changed. If you experience any errors in your application, and send a duplicate change of state, Get will ensure that your application does not collapse.
-The state only changes if the values change. That's the main difference between Get, and using Computed from MobX. When joining two observables, when one is changed, the hearing of that observable will change. With Get, if you join two variables (which is unnecessary computed for that), GetX (similar to Observer) will only change if it implies a real change of state. Example:
+The state only changes if the values change. That's the main difference between Get, and using Computed from MobX. When joining two observables, when one is changed, the hearing of that observable will change. With Get, if you join two variables (which is unnecessary computed for that), GetX (similar to Observer) will only change if it implies a real change of state. 
+
+### Usage:
 ```dart
 final count1 = 0.obs;
@@ -609,6 +423,7 @@ ctl.count.value++
 You could update the counter variable in your UI, regardless of where it is stored.
+### Where .obs can be used
 You can transform anything on obs:
 ```dart
@@ -648,6 +463,7 @@ Camila
 ```
+### Note about Lists
 Working with Lists using Get is the best and most enjoyable thing in the world. They are completely observable as are the objects within it. That way, if you add a value to a list, it will automatically rebuild the widgets that use it.
 You also don't need to use ".value" with lists, the amazing dart api allowed us to remove that, unfortunate primitive types like String and int cannot be extended, making the use of .value mandatory, but that won't be a problem if you work with gets and setters for these.
@@ -665,29 +481,262 @@ You don't have to work with sets if you don't want to. you can use the "assign '
 The "assign" api will clear your list, and add a single object that you want to start there.
 The "assignAll" api will clear the existing list and add any iterable objects that you inject into it.
+### Why i have to use .value?
 We could remove the obligation to use 'value' to String and int with a simple decoration and code generator, but the purpose of this lib is precisely not to need any external dependency. It is to offer an environment ready for programming, involving the essentials (management of routes, dependencies and states), in a simple, light and performance way without needing any external package. You can literally add 3 letters to your pubspec (get) and start programming. All solutions included by default, from route management to state management, aim at ease, productivity and performance. The total weight of this library is less than that of a single state manager, even though it is a complete solution, and that is what you must understand. If you are bothered by value, and like a code generator, MobX is a great alternative, and you can use it in conjunction with Get. For those who want to add a single dependency in pubspec and start programming without worrying about the version of a package being incompatible with another, or if the error of a state update is coming from the state manager or dependency, or still, do not want to worrying about the availability of controllers, whether literally "just programming", get is just perfect.
+
 If you have no problem with the MobX code generator, or have no problem with the BLoC boilerplate, you can simply use Get for routes, and forget that it has state manager. Get SEM and RSM were born out of necessity, my company had a project with more than 90 controllers, and the code generator simply took more than 30 minutes to complete its tasks after a Flutter Clean on a reasonably good machine, if your project it has 5, 10, 15 controllers, any state manager will supply you well. If you have an absurdly large project, and code generator is a problem for you, you have been awarded this solution.
 Obviously, if someone wants to contribute to the project and create a code generator, or something similar, I will link in this readme as an alternative, my need is not the need for all devs, but for now I say, there are good solutions that already do that, like MobX.
+### Obx()
+
 Typing in Get using Bindings is unnecessary. you can use the Obx widget instead of GetX which only receives the anonymous function that creates a widget.
 Obviously, if you don't use a type, you will need to have an instance of your controller to use the variables, or use `Get.find<Controller>()` .value or Controller.to.value to retrieve the value.
-### GetX vs GetBuilder vs Obx vs MixinBuilder
+## Mixing the two state managers
+Some people opened a feature request, as they wanted to use only one type of reactive variable, and the other mechanics, and needed to insert an Obx into a GetBuilder for this. Thinking about it MixinBuilder was created. It allows both reactive changes by changing ".obs" variables, and mechanical updates via update(). However, of the 4 widgets he is the one that consumes the most resources, since in addition to having a Subscription to receive change events from his children, he subscribes to the update method of his controller.
+
+- Note: To use GetBuilder and MixinBuilder you must use GetController. To use GetX and Obx you must use RxController.
+Probably using a GetController using GetX and Obx will work, but it will not be possible to use an RxController on a GetBuilder.
+Extending these controllers is important, as they have life cycles, and can "start" and "end" events in their onInit() and onClose() methods.
+
+## GetX vs GetBuilder vs Obx vs MixinBuilder
 In a decade working with programming I was able to learn some valuable lessons.
+
 My first contact with reactive programming was so "wow, this is incredible" and in fact reactive programming is incredible.
 However, it is not suitable for all situations. Often all you need is to change the state of 2 or 3 widgets at the same time, or an ephemeral change of state, in which case reactive programming is not bad, but it is not appropriate.
+
 Reactive programming has a higher consumption of RAM consumption that can be compensated for by the individual workflow, which will ensure that only one widget is rebuilt and when necessary, but creating a list with 80 objects, each with several streams is not a good one idea. Open the dart inspect and check how much a StreamBuilder consumes, and you'll understand what I'm trying to tell you.
+
 With that in mind, I created the simple state manager. It is simple, and that is exactly what you should demand from it: updating state in blocks in a simple way, and in the most economical way.
+
 GetBuilder is very economical in RAM, and there is hardly a more economical approach than him (at least I can't imagine one, if it exists, please let us know).
+
 However, GetBuilder is still a mechanical state manager, you need to call update() just like you would need to call Provider's notifyListeners().
+
 There are other situations where reactive programming is really interesting, and not working with it is the same as reinventing the wheel. With that in mind, GetX was created to provide everything that is most modern and advanced in a state manager. It updates only what is necessary and when necessary, if you have an error and send 300 state changes simultaneously, GetX will filter and update the screen only if the state actually changes.
+
 GetX is still more economical than any other reactive state manager, but it consumes a little more RAM than GetBuilder. Thinking about it and aiming to maximize the consumption of resources that Obx was created. Unlike GetX and GetBuilder, you will not be able to initialize a controller inside an Obx, it is just a Widget with a StreamSubscription that receives change events from your children, that's all. It is more economical than GetX, but loses to GetBuilder, which was to be expected, since it is reactive, and GetBuilder has the most simplistic approach that exists, of storing a widget's hashcode and its StateSetter. With Obx you don't need to write your controller type, and you can hear the change from multiple different controllers, but it needs to be initialized before, either using the example approach at the beginning of this readme, or using the Bindings class.
-Finally, some people opened a resource request, as they wanted to use only one type of reactive variable, and the other mechanics, and needed to insert an Obx into a GetBuilder for this. Thinking about it MixinBuilder was created. It allows both reactive changes by changing ".obs" variables, and mechanical updates via update(). However, of the 4 widgets he is the one that consumes the most resources, since in addition to having a Subscription to receive change events from his children, he subscribes to the update method of his controller.
-- Note: To use GetBuilder and MixinBuilder you must use GetController. To use GetX and Obx you must use RxController.
-Probably using a GetController using GetX and Obx will work, but it will not be possible to use an RxController on a GetBuilder.
-Extending these controllers is important, as they have life cycles, and can "start" and "end" events in their onInit() and onClose() methods.
+
+
+# Dependency Management
+
+Any contribution is welcome!
+
+## How to use?
+
+<!-- - Flutter Master/Dev/Beta: version 2.0.x-dev 
+- Flutter Stable branch: version 2.0.x
+(look for latest version on pub.dev) -->
+
+Add this to your pubspec.yaml file:
+
+```
+dependencies:
+  get: 
+```
+If you are going to use routes/snackbars/dialogs/bottomsheets without context, or use the high-level Get APIs, you need to simply add "Get" before your MaterialApp, turning it into GetMaterialApp and enjoy!
+
+```dart
+GetMaterialApp( // Before: MaterialApp(
+  home: MyHome(),
+)
+```
+## Navigating without named routes
+To navigate to a new screen:
+
+```dart
+Get.to(NextScreen());
+```
+
+To close snackbars, dialogs, bottomsheets, or anything you would normally close with Navigator.pop(context);
+
+```dart
+Get.back();
+```
+
+To go to the next screen and no option to go back to the previous screen (for use in SplashScreens, login screens and etc.)
+
+```dart
+Get.off(NextScreen());
+```
+
+To go to the next screen and cancel all previous routes (useful in shopping carts, polls, and tests)
+
+```dart
+Get.offAll(NextScreen());
+```
+
+To navigate to the next route, and receive or update data as soon as you return from it:
+```dart
+var data = await Get.to(Payment());
+```
+on other screen, send a data for previous route:
+
+```dart
+Get.back(result: 'success');
+```
+And use it:
+
+ex:
+```dart
+if(data == 'success') madeAnything();
+```
+
+Don't you want to learn our syntax?
+Just change the Navigator (uppercase) to navigator (lowercase), and you will have all the functions of the standard navigation, without having to use context
+Example:
+
+```dart
+
+// Default Flutter navigator
+Navigator.of(context).push(
+  context,
+  MaterialPageRoute(
+    builder: (BuildContext context) { 
+      return HomePage();
+    },
+  ),
+);
+
+// Get using Flutter syntax without needing context
+navigator.push(
+  MaterialPageRoute(
+    builder: (_) { 
+      return HomePage();
+    },
+  ),
+);
+
+// Get syntax (It is much better, but you have the right to disagree)
+Get.to(HomePage());
+
+
+```
+
+### SnackBars
+
+To have a simple SnackBar with Flutter, you must get the context of Scaffold, or you must use a GlobalKey attached to your Scaffold, 
+```dart
+final snackBar = SnackBar(
+  content: Text('Hi!'),
+  action: SnackBarAction(
+    label: 'I am a old and ugly snackbar :(',
+    onPressed: (){}
+  ),
+);
+// Find the Scaffold in the widget tree and use
+// it to show a SnackBar.
+Scaffold.of(context).showSnackBar(snackBar);
+```
+
+With Get:
+
+```dart
+Get.snackbar('Hi', 'i am a modern snackbar');
+```
+
+With Get, all you have to do is call your Get.snackbar from anywhere in your code or customize it however you want!
+
+```dart
+Get.snackbar(
+  "Hey i'm a Get SnackBar!", // title
+  "It's unbelievable! I'm using SnackBar without context, without boilerplate, without Scaffold, it is something truly amazing!", // message
+  icon: Icon(Icons.alarm), 
+  shouldIconPulse: true,
+  onTap:(){},
+  barBlur: 20,
+  isDismissible: true,
+  duration: Duration(seconds: 3),
+);
+
+
+  ////////// ALL FEATURES //////////
+  //     Color colorText,
+  //     Duration duration,
+  //     SnackPosition snackPosition,
+  //     Widget titleText,
+  //     Widget messageText,
+  //     bool instantInit,
+  //     Widget icon,
+  //     bool shouldIconPulse,
+  //     double maxWidth,
+  //     EdgeInsets margin,
+  //     EdgeInsets padding,
+  //     double borderRadius,
+  //     Color borderColor,
+  //     double borderWidth,
+  //     Color backgroundColor,
+  //     Color leftBarIndicatorColor,
+  //     List<BoxShadow> boxShadows,
+  //     Gradient backgroundGradient,
+  //     FlatButton mainButton,
+  //     OnTap onTap,
+  //     bool isDismissible,
+  //     bool showProgressIndicator,
+  //     AnimationController progressIndicatorController,
+  //     Color progressIndicatorBackgroundColor,
+  //     Animation<Color> progressIndicatorValueColor,
+  //     SnackStyle snackStyle,
+  //     Curve forwardAnimationCurve,
+  //     Curve reverseAnimationCurve,
+  //     Duration animationDuration,
+  //     double barBlur,
+  //     double overlayBlur,
+  //     Color overlayColor,
+  //     Form userInputForm
+  ///////////////////////////////////
+```
+If you prefer the traditional snackbar, or want to customize it from scratch, including adding just one line (Get.snackbar makes use of a mandatory title and message), you can use 
+`Get.rawSnackbar();` which provides the RAW API on which Get.snackbar was built.
+
+### Dialogs
+
+To open dialog:
+
+```dart
+Get.dialog(YourDialogWidget());
+```
+
+To open default dialog:
+
+```dart
+Get.defaultDialog(
+  onConfirm: () => print("Ok"),
+  middleText: "Dialog made in 3 lines of code"
+);
+```
+You can also use Get.generalDialog instead of showGeneralDialog.
+
+For all other Flutter dialog widgets, including cupertinos, you can use Get.overlayContext instead of context, and open it anywhere in your code.
+For widgets that don't use Overlay, you can use Get.context.
+These two contexts will work in 99% of cases to replace the context of your UI, except for cases where inheritedWidget is used without a navigation context.
+
+### BottomSheets
+Get.bottomSheet is like showModalBottomSheet, but don't need of context.
+
+```dart
+Get.bottomSheet(
+  Container(
+    child: Wrap(
+      children: <Widget>[
+        ListTile(
+          leading: Icon(Icons.music_note),
+          title: Text('Music'),
+          onTap: () => {}
+        ),
+        ListTile(
+          leading: Icon(Icons.videocam),
+          title: Text('Video'),
+          onTap: () => {},
+        ),
+      ],
+    ),
+  );
+);
+```
+
 ## Simple Instance Manager
 - Note: If you are using Get's State Manager, you don't have to worry about that, just read for information, but pay more attention to the bindings api, which will do all of this automatically for you.
@@ -744,6 +793,7 @@ To remove a instance of Get:
 Get.delete<Controller>();
 ```
+
 ## Bindings 
 One of the great differentials of this package, perhaps, is the possibility of full integration of the routes, state manager and dependency manager.
 When a route is removed from the Stack, all controllers, variables, and instances of objects related to it are removed from memory. If you are using streams or timers, they will be closed automatically, and you don't have to worry about any of that.