From 12caa5a8b1f5428fc567630b3017ad765c587f11 Mon Sep 17 00:00:00 2001 From: Rodinei Fagundes Date: Tue, 5 Oct 2021 17:07:27 -0300 Subject: [PATCH 1/2] Spelling correction --- flutter_modular/lib/flutter_modular.dart | 6 +++--- .../navigation/modular_route_information_parser.dart | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/flutter_modular/lib/flutter_modular.dart b/flutter_modular/lib/flutter_modular.dart index 17e381e9..91c622d4 100644 --- a/flutter_modular/lib/flutter_modular.dart +++ b/flutter_modular/lib/flutter_modular.dart @@ -37,7 +37,7 @@ export 'package:modular_core/modular_core.dart' final Modular = injector(); @visibleForTesting -String initialRouteDeclaratedInMaterialApp = '/'; +String initialRouteDeclaredInMaterialApp = '/'; extension ModularExtensionMaterial on MaterialApp { MaterialApp modular() { @@ -47,7 +47,7 @@ extension ModularExtensionMaterial on MaterialApp { injector.get().setNavigatorKey(navigatorKey); - initialRouteDeclaratedInMaterialApp = initialRoute ?? '/'; + initialRouteDeclaredInMaterialApp = initialRoute ?? '/'; final app = MaterialApp.router( key: key, @@ -95,7 +95,7 @@ extension ModularExtensionCupertino on CupertinoApp { (injector.get() as ModularBase).flags.isCupertino = true; - initialRouteDeclaratedInMaterialApp = initialRoute ?? '/'; + initialRouteDeclaredInMaterialApp = initialRoute ?? '/'; final app = CupertinoApp.router( key: key, diff --git a/flutter_modular/lib/src/presenter/navigation/modular_route_information_parser.dart b/flutter_modular/lib/src/presenter/navigation/modular_route_information_parser.dart index 91271c26..01b02175 100644 --- a/flutter_modular/lib/src/presenter/navigation/modular_route_information_parser.dart +++ b/flutter_modular/lib/src/presenter/navigation/modular_route_information_parser.dart @@ -37,7 +37,7 @@ class ModularRouteInformationParser if (routeInformation.location == null || routeInformation.location == '/') { // ignore: invalid_use_of_visible_for_testing_member - path = initialRouteDeclaratedInMaterialApp; + path = initialRouteDeclaredInMaterialApp; } else { path = routeInformation.location!; } @@ -45,7 +45,7 @@ class ModularRouteInformationParser _firstParse = true; } else { // ignore: invalid_use_of_visible_for_testing_member - path = routeInformation.location ?? initialRouteDeclaratedInMaterialApp; + path = routeInformation.location ?? initialRouteDeclaredInMaterialApp; } return await selectBook(path); From 70ef612bd7ca86ee8da3d3f1a9bcdd13dc179342 Mon Sep 17 00:00:00 2001 From: Jeff Date: Thu, 7 Oct 2021 15:21:54 -0600 Subject: [PATCH 2/2] English translation improvements The meaning of all of the documentation has been preserved. Some alternate words were used or articles of speech adjusted to help the documentation be easier to read. --- .../flutter_modular/dependency-injection.md | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/doc/docs/flutter_modular/dependency-injection.md b/doc/docs/flutter_modular/dependency-injection.md index 94fb26d9..3461bd04 100644 --- a/doc/docs/flutter_modular/dependency-injection.md +++ b/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,7 +196,7 @@ 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(); @@ -204,8 +204,8 @@ Modular.dispose(); ## 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'; @@ -213,7 +213,7 @@ 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'); } }