Merge branch 'master' of https://github.com/Flutterando/modular

Author: jacobaraujo7

doc/docs/flutter_modular/dependency-injection.md

@@ -4,9 +4,9 @@ sidebar_position: 3
 
 # Dependency Injection
 
-We generally code with maintenance and scalability in mind, applying project-specific patterns
-to a given function and improving the structure of our code. We must to pay attention on our code, 
-otherwise it can be a covertly problem. Let's look at the practical example:
+We generally code with maintainability and scalability in mind, applying project-specific patterns
+to a given function and improving the structure of our code. We must pay attention to our code, 
+otherwise it can become a hidden problem. Let's look at a practical example:
 
 ```dart
 class Client {
@@ -27,7 +27,7 @@ Despite being a simple and functional approach, having a class instance within t
 We call it "Dependency Coupling" when we use an outer class in this way, because the *Client* class
 is totally dependent on the functioning of the **XPTOEmail** object.
 
-To break a class's bond with its dependency, we generally prefer to "inject" the dependency instances through constructor, setters or methods. That's what we call "Dependency Injection".
+To break a class's bond with its dependency, we generally prefer to "inject" the dependency instances through a constructor, setters, or methods. That's what we call "Dependency Injection".
 
 Let's fix the **Customer** class by injecting the **XPTOEmail** instance by constructor:
 
@@ -42,11 +42,11 @@ class Client {
   }
 }
 ```
-Thereway, we reduce the coupling **XPTOEmail** object has to the **Client** object.
+This way, we reduce the coupling **XPTOEmail** object has to the **Client** object.
 
 We still have a problem with this implementation. Despite *cohesion*, the Client class has a dependency on an external source, and even being injected by constructor, replacing it with another email service would not be a simple task.
-Our code still have coupling, but we can improve this using `interfaces`. Let's create an interface
-to sign the **sendEmail** method. With this, any class that implements this interface can be injected into the class **Client**:
+Our code still has coupling, but we can improve this using `interfaces`. Let's create an interface
+to define a signature, or "contract" for the **sendEmail** method. With this in place, any class that implements this interface can be injected into the class **Client**:
 
 ```dart
 abstract class EmailService {
@@ -170,7 +170,7 @@ We can get the asynchronous instance directly too without having to convert to a
 ## Auto Dispose
 
 The lifetime of a Bind singleton ends when its module 'dies'. But there are some objects that, by default, 
-runs by an instance destruction routine and automatically removed from memory. Here they are:
+run an instance destruction routine and are automatically removed from memory. Here they are:
 
 - Stream/Sink (Dart Native).
 - ChangeNotifier/ValueNotifier (Flutter Native).
@@ -196,24 +196,24 @@ As BLoC is based on Streams, the memory release takes effect automatically.
 :::
 
 **flutter_modular** also offers a singleton removal option from the dependency injection system 
-calling the **Modular.dispose**() method even with a active module:
+by calling the **Modular.dispose**() method even with an active module:
 
 ```dart
 Modular.dispose<MySingletonBind>();
 ```
 
 ## Hot Reload
 
-The modular is hot-reload friendly, but, singleton binds they are not notified.
-Use ReassembleMixin for this:
+The modular is hot-reload friendly, but, singleton binds are not notified.
+Use the ReassembleMixin for this:
 
 ```dart
 import 'package:flutter_modular/flutter_modular.dart';
 
 class ProductController with ReassembleMixin {
   @override
   void reassemble() {
-    //called when happens the hot reload.
+    //called when the hot reload happens.
     print('reassemble');
   }
 }

flutter_modular/lib/flutter_modular.dart

@@ -37,7 +37,7 @@ export 'package:modular_core/modular_core.dart'
 final Modular = injector<IModularBase>();
 
 @visibleForTesting
-String initialRouteDeclaratedInMaterialApp = '/';
+String initialRouteDeclaredInMaterialApp = '/';
 
 extension ModularExtensionMaterial on MaterialApp {
   MaterialApp modular() {
@@ -47,7 +47,7 @@ extension ModularExtensionMaterial on MaterialApp {
 
     injector.get<IModularNavigator>().setNavigatorKey(navigatorKey);
 
-    initialRouteDeclaratedInMaterialApp = initialRoute ?? '/';
+    initialRouteDeclaredInMaterialApp = initialRoute ?? '/';
 
     final app = MaterialApp.router(
       key: key,
@@ -95,7 +95,7 @@ extension ModularExtensionCupertino on CupertinoApp {
 
     (injector.get<IModularBase>() as ModularBase).flags.isCupertino = true;
 
-    initialRouteDeclaratedInMaterialApp = initialRoute ?? '/';
+    initialRouteDeclaredInMaterialApp = initialRoute ?? '/';
 
     final app = CupertinoApp.router(
       key: key,

flutter_modular/lib/src/presenter/navigation/modular_route_information_parser.dart

@@ -37,15 +37,15 @@ class ModularRouteInformationParser
       if (routeInformation.location == null ||
           routeInformation.location == '/') {
         // ignore: invalid_use_of_visible_for_testing_member
-        path = initialRouteDeclaratedInMaterialApp;
+        path = initialRouteDeclaredInMaterialApp;
       } else {
         path = routeInformation.location!;
       }
 
       _firstParse = true;
     } else {
       // ignore: invalid_use_of_visible_for_testing_member
-      path = routeInformation.location ?? initialRouteDeclaratedInMaterialApp;
+      path = routeInformation.location ?? initialRouteDeclaredInMaterialApp;
     }
 
     return await selectBook(path);