Providers with data accessible across multiple pages

Should Providers with shared data be included in every page it is going to be used?

  selector: 'page-one',
  templateUrl: 'one.html',
  providers: [MySpecialService]

When I do this on more than one page, any variable data in that Provider is not the same across all pages.
Each page starts a new instance of the provider and any data created before is gone.
So I thought that I only had to include the Provider in the app.module.ts:

providers: [{provide: ErrorHandler, useClass: IonicErrorHandler}, MySpecialService]

But if I do that, I get 'No provider for t! errors when I build for release:
ionic build browser --release --prod

So, I can make the data in Provider accessible across all my pages by Not including the provider in each page - But it will not build for release/prod without getting the no provider errors.

Do I need to include the providers somewhere else as well?

Use dependency injection to inject your provider into the constructor of the page or component that needs access to it. Maybe you’re already doing that, but it doesn’t sound that way.

Hi Aaron, yes, I am adding it to the constructor.
constructor(public MySpecialService: MySpecialService)

But I think I just narrowed it down to one particular provider I have created that is causing the problems.
Others work as expected when I remove it.

Thanks for the response though.


That’s precisely what declaring it at the component level is designed to do, so if you want it instantiated as an app singleton, declare it only in the app module.

Ya, that’s what I was doing and it worked until I ran build with --prod. Then it threw the no provider error.
Turned out to be only one problem provider that is a little funky with calls to OneSignal in it. I’m not sure why but it only works if I add the provider at the page level. It is OK for this one as it does not not need to be shared with other pages.
So while it is OK for this project, I will need to dig into it further if I ever want to use as an app singleton elsewhere.