Platform: Question: Example App - RootAuthModule & AuthModule

[phillipzada]

This might be a novice question, but can someone shed some light if there is some special reason in the example app using auth.module.ts providing 2 modules (AuthModule, RootAuthModule) as opposed to a single module?

[changalberto]

@PhillipZada I'm curious too. Good question. =)

[bcabanes]

Seems that they wanted to separate component imports and the nrgx stuff + routes.

[changalberto]

Another novice question:
At the moment I'm having some troubles grasping the structural changes in this new Example App. It is a big departure from the original Example where files were organized by responsibility instead of "modules", can anyone explain to me why this "new" architecture is better over the previous?

[phillipzada]

@changalberto I believe the new structure is to allow for lazy loading of states into your application i.e. dynamic state structure.

[changalberto]

@MikeRyanDev Is this considered a circular reference?

I'm having a bit of trouble comprehending the intent of the two modules here, and how it relates to one another. I'd appreciate it if you could explain the flow here. Thanks!

http://take.ms/Em1gO

[xocomil]

This is also related to lazy loading. In app.config you can now use AuthModule.forRoot() to inject your providers. Then in your feature (lazy loaded), you can use just AuthModule. The benefit to this is that your forRoot() will create one instance of providers with the injector. If you didn't do things this way, you could wind up with multiple instances of your providers (one in the root and one for each feature module). This breaks being able to communicate through services.

[brandonroberts]

Thanks for the explanation @xocomil! Its just a pattern used to separate your root providers from the NgModule itself.

@changalberto its not a circular reference, as the RootAuthModule will be defined when the module file is imported. The RootAuthModule class Its not being accessed until called by the AuthModule.forRoot static method. At that point, both class are defined.

[changalberto]

Thanks! @brandonroberts for clarifying that.

I'm still having a bit of trouble trying to follow the flow/execution order. When RootAuthModule is called while importing AuthModule.forRoot, what is the AuthModule within the import of RootAuthModule decorator essentially doing? Is it just meant to provide the meta information from AuthModule – the module imports and components exports?

I think once I get this part, everything else will become much clearer to me.

Thanks!

[xocomil]

@changalberto The AuthModule.forRoot() goes into the app.module and is only called there. If you notice, the forRoot() sets up the providers array. This makes those services available for the entire application through the DI. In all the other modules, you provide just the AuthModule this makes things like declarations and exports available to the module that uses AuthModule. Again, the reason for this is that the DI in angular is not like the DI in angularjs. In angularjs, providers and factories were singletons and only existed once. In angular, you can have multiple copies of the same service and the DI will inject the appropriate one for your DI context. This isn't really an issue until you do lazy-loading. Once you do that, you have one DI context for the base application and new DI contexts for each of the lazy-loaded modules. If you only ever load providers in the application DI context, they will be injected from there when not found in the lazy-loaded DI context. Does that make sense?

[changalberto]

Perfectly clear now @xocomil. I appreciate it!