Which is the difference between imports and providers in app.module?

[ioclaudio]

Hi,
I’ve seen that in many tutorials that there is a different use of the imports and of the providers section of the file app.module.ts.

@NgModule({
  declarations: [AppComponent],
  entryComponents: [],
  imports: [
    BrowserModule,
    IonicStorageModule.forRoot(),
	....
	],
  providers: [
    StatusBar,
    SplashScreen,
	...
  ],
  bootstrap: [AppComponent]
})
export class AppModule {}

What should go in the import section and what should go in the providers section?
When I create a new service provider should I put in the providers section?

Because when I create a service provider I’m not putting them in the providers section but I’m importing them in each page:

    constructor(
         ...
        private translate: TranslateService,
        private settingsManager: SettingsmanagerService,
       private wsManager: WsmanagerService,**
    ) {

Excuse me for these questions, but I didn’t find a good theoric explanation of these concepts in the Ionic documentation.

Thank you very much

Claudio

[EinfachHans]

As you said a Provider needs to be defined in the provider Section Otherwise you will get an Error when you try to create it in the constructor. In the Imports you can import other Modules.

Tipp: Since a Angular Version (i don’t know exactly which one), you can provide your Services automatically with:

@Injectable({
  providedIn: 'root'
})
export class SomeService {}

[ioclaudio]

@EinfachHans

As you said a Provider needs to be defined in the provider Section Otherwise you will get an Error when you try to create it in the constructor. In the Imports you can import other Modules

Hi,
however, if I don’t put my Provider in the providers section I can use the provider in this way:

import { WsmanagerService } from 'src/app/services/wsmanager.service';

export class ItemDetailPage implements OnInit {

   constructor(
         ...
        private translate: TranslateService,
        private settingsManager: SettingsmanagerService,
       private wsManager: WsmanagerService,**
    ) {}

...
}

So what changes if I put it in the providers section?

cld

[rapropos]

@EinfachHans

you can provide your Services automatically with:

Just because you can doesn’t mean you should. While this seems convenient at first, it has a (for me, anyway) showstopper downside. Ordinary services can be easily mocked out by:

providers: [
  {provide: SomeService, useClass: SomeMock}
]

This becomes impossible when you use providedIn.

@ioclaudio

if I don’t put my Provider in the providers section I can use the provider in this way:

Follow the documentation for whatever library you’re using. If what you are doing here works, it’s likely that you are importing a module that indirectly provides WsmanagerService.

[ioclaudio]

Hi,
I’m not talking about 3rd party libraries, but just providers done by me to implement some logic that I use in many pages of the app.
So I’ve seen that you can just import a Provider on each page in which it is used without importing it in the app.module.ts page.

Which is the problem?
I have the doubt that this is not the right way to use and to import a Provider.

So I’m trying to understand this, if I have a Provider that is used in only one page of the app and a provider that is used in all the pages of the app should they by imported in different ways?

cld

[rapropos]

@ioclaudio

I’ve seen that you can just import a Provider on each page in which it is used without importing it in the app.module.ts page .

I don’t think that’s true, but you can import a provider on each page in which it’s used in addition to declaring it in the imports of your app module.

@ioclaudio

if I have a Provider that is used in only one page of the app and a provider that is used in all the pages of the app should they by imported in different ways?

No.

The reason providers exist on a Component declaration is to scope them to that component, which you almost never want to do. Ordinarily, when page A and page B both inject a provider, they get the same object. That’s generally a super-important desired feature. When page A and page B put the provider in their own Component declaration, they each get a separate instance of the same class. I’m having a hard time thinking of a use case where one would actually want that.