UnregisteredInstance after update to 6.1.1

[pedromellofh]

after update to modular 6.1.1 I'm getting an UnregisteredInstance after the bindings. I saw the auto_injector got some changes in da310a0

I've tried to add a "key" to the bindings and it only change the class it can't found. I suspect the absent 'key' may be the culprit

[jacobaraujo7]

Olá.
Acredito que fiz a correção pra esse problema, está em beta por enquanto.
Estamos avaliando.

[allanwolski]

O mesmo problema aqui.

[pedromellofh]

testei com a versão 6.2.0-beta.4, mas o problema se manteve

[jacobaraujo7]

Corrigido o bug:
Quando era registrado uma instância em um Módulo ancestral ele ficava disponível para os filhos
automaticamente. Isso gerava problemas de compreenção quando o módulo estava separado do app base.
Agora recomendamos a criação de um Módulo global, exportar os binds e importar nos módulos.

[pedromellofh]

como são binds do app_module, eu moveria para exportBinds e usaria import nos modulos filhos. isso? No caso de binds que usam outros binds do mesmo módulo, teria de importar no app_module tb?

[jacobaraujo7]

Isso.
Mas eu sugiro que crie um Módulo como CoreModule ou CommonModule e coloque lá todos os dados globais.

[leobidoous-gen]

@jacobaraujo7 nao é possivel mudar o ciclo de vida para chamar primeiramente o binds e depois o imports? Quando eu chamo meu AppModule, ele tem minhas injections globais (um controller de logs, por exemplo) que eu injeto no binds do próprio AppModule. Essa mesma classe de logs é usada em AuthModule, que eu injeto em AppModule atraves do import do AppModule. Mas quando rodo o app, da erro de que nao foi possivel encontrar essa classe de log em AuthModule, pois ele ainda nao foi injetado em AppModule.

[jacobaraujo7]

@jacobaraujo7 nao é possivel mudar o ciclo de vida para chamar primeiramente o binds e depois o imports? Quando eu chamo meu AppModule, ele tem minhas injections globais (um controller de logs, por exemplo) que eu injeto no binds do próprio AppModule. Essa mesma classe de logs é usada em AuthModule, que eu injeto em AppModule atraves do import do AppModule. Mas quando rodo o app, da erro de que nao foi possivel encontrar essa classe de log em AuthModule, pois ele ainda nao foi injetado em AppModule.

Sendo assim não seria melhor importar o controlador de logs a partir de um CoreModule?
No ciclo de vida atual primeiro são resolvidos os exports depois os binds, mas os binds exports do módulo não sao visiveis no módulo current.

[leobidoous-gen]

@jacobaraujo7 nao é possivel mudar o ciclo de vida para chamar primeiramente o binds e depois o imports? Quando eu chamo meu AppModule, ele tem minhas injections globais (um controller de logs, por exemplo) que eu injeto no binds do próprio AppModule. Essa mesma classe de logs é usada em AuthModule, que eu injeto em AppModule atraves do import do AppModule. Mas quando rodo o app, da erro de que nao foi possivel encontrar essa classe de log em AuthModule, pois ele ainda nao foi injetado em AppModule.

Sendo assim não seria melhor importar o controlador de logs a partir de um CoreModule? No ciclo de vida atual primeiro são resolvidos os exports depois os binds, mas os binds exports do módulo não sao visiveis no módulo current.

@jacobaraujo7 também tentei fazer isso, mas acontecem alguns problemas:

No App Module eu estou importando as dependencias globais do meu app, as que uso em AppModule e AuthModule, como a eventLog e crashLog.
No entando, quando executo o app, AuthModule nao encontra as dependencias ja injetadas em AppModule atraves do import. Como uso microfront baseado em packages, AuthModule nao tem acesso a algumas classes que eu optei por colocar apenas no base_app, como o EnvironmentEntity. O que ocorria de forma fácil no modular 5.x era a definicao dos AuthModule.exportedBinds dentro dos binds do AppModule e as dependencias ficavam no escopo global. Agora, aparentemente, a solucao seria colocar GlobalModule tambem dentro de AuthModule, mas pra que, se eu ja to colocando ele em AppModule que, em teoria, daria acesso a todos os meus outros módulos?

Outro fator que nao deveria influenciar no Modular 6.x era o commit do auto_injector, mas sempre recebo este alerta quando executo o app:

[jacobaraujo7]

@leobidoous-gen POde me mostrar aqui no discord?

[FernandoUFS]

Também estou exatamente com o mesmo problema, tenho um CoreModule no meu imports, e meu outro módulo não consegue enxergar nenhuma dependência do CoreModule.
Estou com a versão flutter_modular: ^6.3.1

class AppModule extends Module {
  final Isar isar;
  final SharedPreferences sharedPreferences;

  AppModule(this.isar, this.sharedPreferences);

  @override
  List<Module> get imports => [
        CoreModule(isar, sharedPreferences),
        TicketsModule(),
      ];

  @override
  void routes(RouteManager r) {
    r.child('/', child: (context) => const HomePage());
  }
}

Meu TicketsModule.exportedBinds() não encontra Isar, nem SharedPreferences, nem outros exportedBinds do CoreModule importado no módulo pai.

Nem mesmo numa segunda tentativa, onde tentei importar o CoreModule dentro do TicketsModule.
(Além de ter que passar parâmetros de classe em classe por causa da remoção do AsyncBinds)

lass TicketsModule extends Module {
  final Isar isar;
  final SharedPreferences sharedPreferences;

  TicketsModule(this.isar, this.sharedPreferences);

  @override
  List<Module> get imports => [
        CoreModule(isar, sharedPreferences),
      ];

  @override
  void exportedBinds(Injector i) {
    i.add<TicketsDataSource>(IsarTicketsDataSource.new);
    i.add<TicketsRepository>(TicketsRepositoryImpl.new);
    ...
  }

O erro é recebido:

The injector(tag: TicketsModule_Imported) is not committed.
It is recommended to call the "commit()" method after adding instances.
UnregisteredInstance: Isar not registered.
Trace: TicketsRepository->TicketsDataSource->Isar
TicketsRepository => TicketsDataSource => Isar
package:auto_injector/src/auto_injector_base.dart 261:7                    AutoInjectorImpl.get
package:auto_injector/src/auto_injector_base.dart 32:12                    Injector.call
package:casadasapostas3/core/features/tickets/tickets_module.dart 98:10    TicketsModule.exportedBinds
package:modular_core/src/tracker.dart 260:22                               _Tracker._createExportedInjector
package:modular_core/src/tracker.dart 271:30                               _Tracker._createInjector
package:modular_core/src/tracker.dart 202:25                               _Tracker.bindModule
package:flutter_modular/src/infra/services/module_service_impl.dart 25:13  ModuleServiceImpl.bind
package:flutter_modular/src/domain/usecases/bind_module.dart 17:26         BindModuleImpl.call

[jacobaraujo7]

Também estou exatamente com o mesmo problema, tenho um CoreModule no meu imports, e meu outro módulo não consegue enxergar nenhuma dependência do CoreModule. Estou com a versão flutter_modular: ^6.3.1

class AppModule extends Module {
  final Isar isar;
  final SharedPreferences sharedPreferences;

  AppModule(this.isar, this.sharedPreferences);

  @override
  List<Module> get imports => [
        CoreModule(isar, sharedPreferences),
        TicketsModule(),
      ];

  @override
  void routes(RouteManager r) {
    r.child('/', child: (context) => const HomePage());
  }
}

Meu TicketsModule.exportedBinds() não encontra Isar, nem SharedPreferences, nem outros exportedBinds do CoreModule importado no módulo pai.

Nem mesmo numa segunda tentativa, onde tentei importar o CoreModule dentro do TicketsModule. (Além de ter que passar parâmetros de classe em classe por causa da remoção do AsyncBinds)

lass TicketsModule extends Module {
  final Isar isar;
  final SharedPreferences sharedPreferences;

  TicketsModule(this.isar, this.sharedPreferences);

  @override
  List<Module> get imports => [
        CoreModule(isar, sharedPreferences),
      ];

  @override
  void exportedBinds(Injector i) {
    i.add<TicketsDataSource>(IsarTicketsDataSource.new);
    i.add<TicketsRepository>(TicketsRepositoryImpl.new);
    ...
  }

O erro é recebido:

The injector(tag: TicketsModule_Imported) is not committed.
It is recommended to call the "commit()" method after adding instances.
UnregisteredInstance: Isar not registered.
Trace: TicketsRepository->TicketsDataSource->Isar
TicketsRepository => TicketsDataSource => Isar
package:auto_injector/src/auto_injector_base.dart 261:7                    AutoInjectorImpl.get
package:auto_injector/src/auto_injector_base.dart 32:12                    Injector.call
package:casadasapostas3/core/features/tickets/tickets_module.dart 98:10    TicketsModule.exportedBinds
package:modular_core/src/tracker.dart 260:22                               _Tracker._createExportedInjector
package:modular_core/src/tracker.dart 271:30                               _Tracker._createInjector
package:modular_core/src/tracker.dart 202:25                               _Tracker.bindModule
package:flutter_modular/src/infra/services/module_service_impl.dart 25:13  ModuleServiceImpl.bind
package:flutter_modular/src/domain/usecases/bind_module.dart 17:26         BindModuleImpl.call

Peria testar na versao 6.3.2?

[FernandoUFS]

@jacobaraujo7
Houve um avanço, para o exemplo de baixo que mostrei, onde o Core é importado diretamente no submodule do TicketsModule, a dependência é encontrada com sucesso aqui, a atualização resolveu o problema nessa parte.

i.add<TicketsDataSource>(IsarTicketsDataSource.new);
i.add<TicketsRepository>(TicketsRepositoryImpl.new);

Mas agora surge outro problema logo em baixo onde uso um addInstance. Nesse ponto do addInstance não encontra as dependências.

i.addInstance(
      DetectDatabaseAndImportItAutomaticallyUseCase(
        i(),
        i(),
        i(),
        i(),
        OldAppTicketsRepositoryImpl(
          i<BlueAppOldAppTicketsDataSource>(),
        ),
        OldAppTicketsRepositoryImpl(
          i<ZenAppOldAppTicketsDataSource>(),
        ),
      ),
    );

Ele fica dando aquela mensagem de erro:

It is recommended to call the "commit()" method after adding instances.

O uso desse commit() faria o addInstance resolver as dependências?

Já para os imports do parent, não reconhece nem aí. Imagino que tenha a ver com o Phantom Dependencies fix da 6.3.0, tem alguma issue ou discussion do porquê da alteração? Porque pra fazer a migração do v5 para o v6, agora com vários submódulos, to tendo que repassar várias async dependencies resolvidas no main, pra dentro de cada módulo até chegar no submódulo que pretendo incluir com o CoreModule, há alguma recomendação pra evitar isso? Instanciar o CoreModule no main.dart como variável global e usar a instância seria uma solução adequada? Na v5 os imports passavam para os filhos, e aqui estava funcionando tudo ok dessa forma.

[jacobaraujo7]

@FernandoUFS Pq vc está usando assim em vez de:

i.add(DetectDatabaseAndImportItAutomaticallyUseCase.new);
i.add(OldAppTicketsRepositoryImpl.new);
i.add(OldAppTicketsRepositoryImpl.new);

?