Comments (13)
Olá @adrinebt,
Veja essa parte da documentação com a comparação: https://modular.flutterando.com.br/docs/flutter_modular/migration-5-to-6
from modular.
Minha dúvida é sobre como lidar com o caso do construtor de LoginController que tem as dependências IUsuarioService, IConfiguracaoAppService como funcionaria na migração não encontrei nada parecido na documentação
@override
final List<Bind> binds = [
Bind.lazySingleton((i) => LoginController(
i.get<IUsuarioService>(),
i.get<IConfiguracaoAppService>(),
i.get<LoginRepository>(),
i.get<UsuarioModel>(),
),
),
Bind.lazySingleton((i) => LoginRepository()),
Bind.lazySingleton((i) => UsuarioModel())
];
from modular.
IUsuarioService
e IConfiguracaoAppService
estão no binds
de outro Módulo? Se sim, pode mostrar o nome desse outro módulo e a parte do binds dele para eu te dar um exemplo correto?
from modular.
Outro exemplo é no módulo do Splash que vem antes do login que mostrei anteriormente
class SplashModule extends Module {
@override
final List<Bind> binds = [
Bind.lazySingleton((i) => SplashController()),
Bind.lazySingleton((i) => LoginController(
i.get<IUsuarioService>(),
i.get<IConfiguracaoAppService>(),
i.get<LoginRepository>(),
i.get<UsuarioModel>(),
),
),
];
@override
final List<ModularRoute> routes = [
ChildRoute(Modular.initialRoute, child: (_, args) => const SplashPage()),
];
}
from modular.
Para te dar o exemplo na versão 6 corretamente, eu precisaria saber onde são declaradas as dependências IUsuarioService
e IConfiguracaoAppService
. Elas estão no binds
seu AppModule
ou num SharedModule
? Ou elas estão no binds
do LoginModule
e SplashModule
, só que você cortou ao colocar o código nos exemplos acima?
Ou seja, no LoginModule
e SplashModule
, que mostrou acima, você obtém essas dependências (IUsuarioService
e IConfiguracaoAppService
), mas em algum módulo anterior você colocou essas dependências no binds
para serem usadas posteriormente.
from modular.
IUsuarioService e IConfiguracaoAppService são dependências de LoginController e declaradas em LoginModule.
este por sua vez é declarado no AppModule como no código abaixo
@override
final List<ModularRoute> routes = [
ModuleRoute(Modular.initialRoute, module: SplashModule()),
ModuleRoute(routeLogin, module: LoginModule()),
ModuleRoute(routeHome, module: HomeModule()),
ModuleRoute(routeConsulta, module: ConsultaModule()),
];
from modular.
Ok, acredito que não tenha você não compreendeu a informação que preciso, mas vou te dar um exemplo de como eu faria na versão 6 do Modular:
- Como
IUsuarioService
eIConfiguracaoAppService
serão usados em mais de um módulo, o ideal é colocá-los num módulo à parte com exportação. Vou supor queIUsuarioService
eIConfiguracaoAppService
são interfaces eUsuarioServiceImpl
eConfiguracaoAppServiceImpl
são as implementações destas interfaces. Faça umCoreModule
desta forma:
class CoreModule extends Module {
@override
void exportedBinds(Injector i) {
i.addSingleton<IUsuarioService>(UsuarioServiceImpl.new);
i.addSingleton<IConfiguracaoAppService>(ConfiguracaoAppServiceImpl.new);
}
}
- Seu
LoginModule
, importaráCoreModule
e ficará então desta forma:
class LoginModule extends Module {
@override
List<Module> get imports => [CoreModule()];
@override
void binds(Injector i) {
i.addLazySingleton(LoginController.new),
i.addLazySingleton(LoginRepository.new),
i.addLazySingleton(UsuarioModel.new)
}
@override
void routes(RouteManager r) {
r.child(Modular.initialRoute, child: (context) => const LoginPage()),
}
}
Ao fazer LoginController.new
o sistema de injeção de dependências fará a injeção automática de cada dependência que LoginController
precisa via construtor, basta que exista um bind dessas dependências, que foi o que fiz nos exemplos acima.
from modular.
Perdão, não sei se essa era a sua dúvida agora creio que compreendi. IUSuarioService e IConfiguracaoAppService são de fato interfaces implementadas respectivamente em UsuarioService e ConfiguracaoAppService que como no código abaixo estão declaradas nos binds do AppModule
@override
final List<Bind> binds = [
Bind.lazySingleton((i) => ConfiguracaoAppService()),
Bind.lazySingleton((i) => UsuarioService(i<IUsuarioRepository>())),
Bind.lazySingleton((i) => CustomDio(i<BaseOptions>())),
Bind(
(i) => BaseOptions(
baseUrl: baseUrlNova,
contentType: Headers.formUrlEncodedContentType,
connectTimeout: const Duration(seconds: 90),
receiveTimeout: const Duration(seconds: 90),
sendTimeout: const Duration(seconds: 90),
receiveDataWhenStatusError: true,
),
),
];
from modular.
Isso mesmo que eu estava querendo saber.
Esse Bind que mostrou agora por último ficará assim:
class CoreModule extends Module {
@override
void exportedBinds(Injector i) {
i.addLazySingleton<IConfiguracaoAppService>(ConfiguracaoAppService.new);
i.addLazySingleton<IUsuarioService>(UsuarioService.new);
i.addLazySingleton<CustomDio>(CustomDio.new),
i.addInstance<BaseOptions>(
() => BaseOptions(
baseUrl: baseUrlNova,
contentType: Headers.formUrlEncodedContentType,
connectTimeout: const Duration(seconds: 90),
receiveTimeout: const Duration(seconds: 90),
sendTimeout: const Duration(seconds: 90),
receiveDataWhenStatusError: true,
),
),
}
}
Em cada módulo que precisar do IConfiguracaoAppService
e IUsuarioService
, você precisará importar este CoreModule como mostrei no exemplo anterior em LoginModule. Essa é a orientação no Modular 6 (No 5 não precisava)
from modular.
Obs.: Não use o AppModule para fazer esse exportedBinds das dependências que serão compartilhadas, use um módulo em separado (orientação para modular 6) como o CoreModule do meu exemplo. Se até o AppModule precisar das dependências, pode importar também.
from modular.
Interessante, não fiz a migração por conta disso, não havia entendido.
from modular.
nesse caso o AppModule serviria somente para declarar os modules como SplashModule, LoginModule?
from modular.
nesse caso o AppModule serviria somente para declarar os modules como SplashModule, LoginModule?
Sim, você até pode colocar bind nele, mas seria só de dependências que seriam usadas exclusivamente no AppModule, caso ele tivesse uma página inicial, antes de ir para outro módulo, por exemplo.
Obs.: Você consegue acessar um bind do AppModule em qualquer outro módulo declarado por ele, fazendo Modular.get<SuaDependencia>()
, mas isso não é aconselhável, pois "estraga" a sua arquitetura, já que seria por fora da injeção de dependências.
from modular.
Related Issues (20)
- ChildRoute fails to render if it has RouterOutlet
- My modular cannot register Client and Network HOT 6
- Deep links and universal links fail to navigate to the correct screen when the app is already open. HOT 1
- Incompatible dependency version HOT 4
- Losing browsing history on Flutter Web HOT 1
- Injeçao de Dependencias HOT 13
- Properties lost in Singleton binding defined on shared module HOT 1
- Unable to navigate accross child modules HOT 1
- How to wrap all Resource functions in the same error handling function in order to reduce boilerplate? (Sheld_Modular) HOT 2
- WebUrlService not compatible with Flutter Web apps deployed outside of root path HOT 1
- flutter-modular-stack-overflow-error
- RouterOutlet navigation problem HOT 7
- Modular breaks the application with double click HOT 3
- erro codigo flutter HOT 1
- erro no flutter HOT 1
- PositionalParam is required and replaceInstance in cascade HOT 1
- New Modular Version brokes Query Params HOT 3
- Is possible use Deferred components for big modules?
- RouterOutlet routes persist even when parent route is popped HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from modular.