Skip to content

Commit

Permalink
Merge branch 'master' of https://github.com/Flutterando/modular
Browse files Browse the repository at this point in the history
  • Loading branch information
jacobaraujo7 committed Oct 8, 2021
2 parents bb77838 + b3c851d commit b91208f
Show file tree
Hide file tree
Showing 3 changed files with 17 additions and 17 deletions.
24 changes: 12 additions & 12 deletions doc/docs/flutter_modular/dependency-injection.md
Original file line number Diff line number Diff line change
Expand Up @@ -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 {
Expand All @@ -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:

Expand All @@ -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 {
Expand Down Expand Up @@ -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).
Expand All @@ -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');
}
}
Expand Down
6 changes: 3 additions & 3 deletions flutter_modular/lib/flutter_modular.dart
Original file line number Diff line number Diff line change
Expand Up @@ -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() {
Expand All @@ -47,7 +47,7 @@ extension ModularExtensionMaterial on MaterialApp {

injector.get<IModularNavigator>().setNavigatorKey(navigatorKey);

initialRouteDeclaratedInMaterialApp = initialRoute ?? '/';
initialRouteDeclaredInMaterialApp = initialRoute ?? '/';

final app = MaterialApp.router(
key: key,
Expand Down Expand Up @@ -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,
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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);
Expand Down

0 comments on commit b91208f

Please sign in to comment.