Best practice for app.module in Ionic 2 RC0

Ionic Framework ionic-v3
1

Hey folks!

I’m going through the upgrade path to get to RC0 and whew, it’s a doozy. But right now I’m trying to understand the best practice for app.module. Looking at the ionic-conference-app as an example, it would seem as though every page in the app should go in both the declarations and entry components. And then every provider should go in the providers section. … And then we should no longer user the providers property when defining a component.

Is all of that correct? And if so, it is best practice, or should we have multiple modules in a project, separated by feature area (akin to modules in angular 1), and then import those feature modules into the app module with the imports property?

Thanks for your time!

4 Likes
2

I have a similar question, but just revolving around entryComponents. I was under the impression that entry components was going to be deprecated in RC6+, but I guess it hasn’t been.

1 Like
3

I also wonder this, would be great if the ionic team could give us an explanation of how we are supposed to use this new app structure with the NgModel and everything.

4

In my case i don’t understand how we now declare providers in projects…my projects all failed when i try to import provider in pages :confused:

5

@gsoulie as far as I understood you don’t need to declare your providers in each page anymore. You actually can’t since ‘providers’ is not part of the object in ‘@Component’ anymore.
Now you just put them in the @NgModule object inside app.module.ts. They should be accessible all over your app. (Actually the module, but if you follow the migration guide your entire app will be inside one module).

1 Like
6

Acording to Angular.io docs, the modules have to declare the providers and not the components unless you have a very good reason to hide the service to other components, making it lazy loaded, but you shouldn’t. As @MrFloppy says, all ngmodule providers become app-wide available anyway so having them inside the app.module should be ok. The injector handles this. Dependency injection

The thing I’m having a hard time to get is: how should we structure different features throughout the application? Should we have domain and routed feature modules as the NgModule FAQ says? feature-modules. And if so:

  • How to import and navigate to different modules? (If I add another module to the app.module imports as Angular.io examples, IonicModule seems to stop working)

  • How is this affecting AoT compilation?

  • How does it affect performance?

2 Likes
7

I created an ionic2.rc0 project using angular2 modules structure.
It’s based on the blank project.
The only thing I don’t like, is how to navigate between modules.

Here you can have a look and tell me what you think about it: https://github.com/JumBay/ionic2-modules-structure

2 Likes
8

For creating custom modules.

Ex. LoginModule and MainModule

inside @NgModule of MainModule

  1. “declarations” and “entryComponents”: [MainPage, SubMainPage]
  2. “providers”: [MainProvider]
  3. “imports”: [IonicModule] //required
  4. “exports”: [MainPage] - this will allow LoginPage to navigate to this page since it became public

inside @NgModule of LoginModule

  1. “declarations” and “entryComponents”: [LoginPage, SignupPage]
  2. “providers”: [UserProvider]
  3. “imports”: [IonicModule, MainModule] //LoginModule can now access to the exported page from MainModule
  4. “exports”: [LoginPage] - this will allow AppModule to navigate to this page since it became public

inside @NgModule of AppModule
import LoginModule

NOTE:

  1. On this structure, AppModule can’t access to MainModule without going to LoginModule.
1 Like
9

Thanks for the explanations! Sounds very logical to me!
Do you have any reference to best practice for the actual codes of how to transition between modules? is it using navController’s setRoot, setPage? Thanks :slight_smile:

1 Like
10

Well i have the same question, i think it was partialy solved here, just dont get it the diference on “declarations” and “entryComponents”, and why everything is on both decorators.

11

I like the idea of structuring an app in different modules as @JumBay shows in the link.

As long as ionic 2 does not support lazy loading it should be not that much of a problem, but as soon as it does, you get different instances of services (“providers”) that should be singletons because you have to import IonicModule into every of your modules.

In addition IonicModule reexports BrowserModule into every of your modules that need ionic directives or components although angular docs recommend to import BrowserModule only once in your RootModule and use CommonModule instead in each of your other modules.

Does somebody has a good solution to avoid this?

12

This is for dynamically added components that are added using ViewContainerRef.createComponent(). Adding them to entryComponents tells the offline template compiler to compile them and create factories for them.

The components registered in route configurations are added automatically to entryComponents as well because router-outlet also uses ViewContainerRef.createComponent() to add routed components to the DOM.

https://angular.io/docs/ts/latest/api/core/index/NgModule-interface.html#!#entryComponents-anchor

Defines the components that should be compiled as well when this component is defined. For each components listed here, Angular will create a ComponentFactory and store it in the ComponentFactoryResolver.
If you don’t list a dynamically added component to entryComponents you’ll get an error message a bout a missing factory because Angular won’t have created one.

See also https://angular.io/docs/ts/latest/cookbook/dynamic-component-loader.html

1 Like