Usage of Flutter Modular to deal with dependency injection, routing and auto-dispose

[pedrolemoz]

Usage of Flutter Modular in the project

In the Brazilian comunnity, Flutter Modular is one of the most used packages. This package show us an approach to modularize our code in a manner that code reutilization is the main focus. Also, the package has it's own abstraction of the original Navigator class, that don't need the actual context to work properly (this is very appropriated when we want to switch between pages using the app controller).

You can see the official docs here.

The usage is very simple: we have the main.dart file executing the runApp function, as expected. But, instead of passing a Stateless/Stateful MaterialApp widget, we just pass a AppModule widget.

In this project, I have two different flavors: production and development. Each flavor has it's own main.dart file, and that's why I'm passing a specific ServerConfiguration in the constructor of AppModule. This is not usual, but works great.

Then, the AppModule will look like this:

First, we have the binds. This is where we can register our dependencies, and also decide if we want a singleton or not, as well if the bind will be lazy or not.

The i() function is very helpful to get the dependencies in the class constructor, since we don't need to specify the exact instance of the class, or even the type. This process is automatic.

Then, we'll have the ChildModules. These modules are usually sections of the app. For example, we can have an authentication module, home module, cart module, etc... We'll define all the ChildModules in the routers of AppModule.

Finally, our app entry point will be the bootstrap widget from the AppModule. In this case, AppWidget.

Our ChildModule will look like this:

The bindings are similar to those defined in AppModule. The difference here is the scope: all the bindings defined in AppModule will remain until the app is closed. The bindings defined in any child module will only be used inside that module, and will be disposed when the module is closed (usually when the user is not accessing a page within that module). This give us a better overall performance by optimizing the used memory.

In order to access a binding, we use the Modular.get<T>() function.

Since we don't need a context to navigate between pages, is safe to use the controller for this:

We can pass strings into the route:

And we also can pass objects:

This was a brief explanation of the package and it's benefits. More details can be found in the internet, and also in the Brazilian community, as the package is very used.

[matuella]

Hello @pedrolemoz, and thanks for your contribution!

So, I took the time to read your suggestion and more about the Flutter Modular package, and I found it to be quite an interesting package, so thanks for bringing this up for discussion.

I liked the fact the it is a solution that tackles many problems at the same time, but the relevant ones to this use in this project I think it would be routing and dependency injection. The problem that I see to include this package and use throughout the project is:

1. we have decided to use river_pod, which we are using to provide all dependencies to multiple, and we think it's a lightweight solution that is an improvement over the classic provider and bloc, you can read more about the package in its repository;
2. we implemented the navigator using the navigator 2.0 approach. While we didn't quite liked it (and it appears that neither the Flutter team did, so they are doing a re-work on it), we still think that it's easy to scale to complex flows.

I think is a really good package for a good amount of applications out there, but given the dependencies that we are using to provide DI (that is detached from the Flutter framework) and the native Navigator 2.0 (or Router) solution, we will stick to these until either they prove to be a burden other than a help, or if there is a clear better package (or native solution) to achieve the aforementioned goals.

Again, thanks for taking your time to help improving memo!

[luizwalber]

Modular 3.0 is build using the Navigator 2.0

The Navigator 2.0 is complex, so the flutter team is analyzing the packages build based on Navigator,

so far Modular 3.0 doesn't meet only one of the requirements (Skipping Stacks), you can check the discussion here