Util events in Ionic 4 and 5?

In Ionic Angular 3 there was import { Events } from 'ionic-angular'; . In Ionic Angular 4 and Ionic Angular 5 it seems like there are only events coupled to specific elements. What can be used in v4 and v5 instead of the v3 utilities? Sould I use custom Angular EventEmitters instead?

EDIT: In my case it’s about communication between 2 unrelated aka “sibling” components.


Use BehaviorSubject, which is strictly typed version of an event bus. Avoids many issues you will get with the Event system

I’m primarily a backend developer. For that reason it’s quite unclear for me right now what to use for what type of event based communication. The recommendations I came across so far are as follows:

  • parent to child component → @Input()
  • child to parent component → ViewChild / @Output() + EventEmitter
  • between unrelated/sibling components → Service

What’s your opinion about that?



Check Angular

That is the definitive guide which maybe is worthwhile going through.

All three have a purpose in an Angular app.

The EventEmitter I would forget besides being part of the @Output syntax

For passing data between different components, I sometimes use this:

To replace missing Events from ionic, I use this:

Note: Some people here will tell you this is ‘wrong’ and not the ‘Angular’ way of doing things, that’s their opinion and they’re entitled to it. I don’t think there is a right or wrong way, just what works for you and does the job.
This works for my needs.

It seems like a “shared” Service with BehaviourSubject whose skeleton can be generated with (ionic generate service --help <service-name>) is what I’m looking for w.r.t. communicating/sharing state.

then if you combine that with the BehaviorSubject pattern, then you assure you have one single source of the truth which is up-to-date present in all parts of the app - and no need to hardwire component lifecycles in your data getters.

Thx, but I like the solution with BehaviourSubject better.

One of the links here refers an explanation about how to do this :wink:

1 Like

Yeah, Fireship rocks!!!

Subscribe to their youtube channel (if you haven’t already). Cool updates

1 Like

@Tommertom One additional thing I’m missing is an “event handler” in a component which shall trigger if the shared state changes… any idea?

The component needs to subscribe to the serivce provider’s exposed observable. In angular this can also be done using the async pipe in the template. This helps a lot avoiding boilerplate.

A state change needs to go to the service which emits the new value to whoever subscribed to it next(mynewvalue)

Component ts

someDataToObserve$:Observable<MyDataInterface | undefined>;



component template:

{{someDataToObserve$ | async | json }}

Service provider

myDataBHSubjectIDontWantToExposeDirectly$:BehaviorSubject<MyDataInterface | undefined>=new BehaviorSubject(undefined);


giveMeData$():Observable<MyDataInterface | undefined> {
   return this.myDataBHSubjectIDontWantToExposeDirectly$.asObservable();

Thx. I’ll look into this next week.

/me raises hand, I guess.

This time, though, for me, it’s not about “the ‘Angular’ way of doing things” as much as it’s about separation of concerns and encapsulation.

Maybe it’s because I make lots of stupid mistakes in the first place, but I find I spend a lot of my time finding and quashing bugs and maintaining and extending software.

I expect everybody here has had that experience where you inherit (this includes coming back to something you wrote earlier and forgot the nuances of) a complicated codebase and have to modify it. The hardest part is knowing what you can safely touch without breaking other things.

Furthermore, I expect everybody has also had the experience of getting a bug report and having absolutely no idea how it could possibly be happening, and barely even a notion of where to start looking. The quicker you can isolate the potentially problematic code, the more efficient your debugging is.

Combining these two situations is frequently lethal. There’s a bug, and I think you know how to fix it, but then my “fix” has unintended consequences for some other part of the program, because everything is all snarled together. So what I end up having to do instead is rewrite the entire program, which (I tell myself) is justifiable anyway, because now I can use whatever shiny new buzzy framework everybody is talking about, instead of that old clunky one I was using.

Which brings me to Events and why I hate them. First off, there is a huge tendency (I have done this to myself) to use them to implement RPC, or “action at a distance”. That’s where we are in section A of the program and we really need section B to do something. Call it tight coupling, call it failure of encapsulation, call it spaghetti: the bottom line is that these interconnections are exactly the cause of bugs that are hard to track down and bugs that are hard to fix because the fix breaks other things. The fewer of them we have, the better.

And, just as importantly, the ones that we do need must be rigorously documented, and for that we need all the help we can get. Fortunately, TypeScript and RxJS offer a lot of help here, as does Angular DI. When you use Observables, they can be strongly typed, and it is easy to discover what code depends on what - the dependencies must be declared in the constructor. You are protected from stupid misspellings by the build tools, and you have all the scheduling infrastructure that is baked into ReactiveX. With Events you end up reinventing all that (and what more typically happens is that we’re in a hurry and just don’t bother, so we’ve created a maintenance headache for the future).

TL;DR: Anything Events can do, Observables can do in a much more maintainable and error-resistant way.