Events not worked in ionic 6.1.0

import { Events} from ‘@ionic/angular’;

when i tried the previous import i receive next error

Module ‘"…/…/…/…/node_modules/@ionic/angular/ionic-angular"’ has no exported member ‘Events’.

import { Events } from ‘ionic-angular’;

add “Events” under provider in app.module.ts

as ionic new release feedback, this feature is deprecated, i am not understand the concept of observable, i need to do service like events has key and value and allowed publishing and subscribing

RxJS is such an integral part of Angular that I think it would really improve your life if you studied it a bit. IMHO, Ionic Events never should have existed in the first place.

can you give example using observable like event, by creating small service with publish and subscribe function please, thank you

Below using “events.subscribe…” you can create the global function on any page and then you can call/trigger this function using event.publish…‘default and updatemenu is ths name of subscription’

//first global function on app.componant.ts

events.subscribe(‘session:default’, (flag) => {
// console.log(‘calling’);

//second global function on app.componant.ts

  events.subscribe('session:updatemenu', (flag) => {

from login.ts page you can call/trigger above function like below

@sanjay100 thank you, i already used liked this, but this feature now is deprecated in new version, and i am looking for using observable

Out of curiosity, when did Ionic 6.1.0 released?

A few days back, Ionic 5 was released. Can you please double-check the version and update your topic.

And by the way, Events are removed in Ionic 5. Please check in the breaking changes

You can use observables. For example, create a global service:

import {Injectable} from '@angular/core';
import {Subject} from 'rxjs';

    providedIn: 'root'
export class GlobalFooService {

    private fooSubject = new Subject<any>();

    publishSomeData(data: any) {;

    getObservable(): Subject<any> {
        return this.fooSubject;

Now, for example, you are subscribing to it in app.component.ts:

    selector: 'app-root',
    templateUrl: 'app.component.html',
    styleUrls: ['app.component.scss']
export class AppComponent {

    constructor(private globalFooService: GlobalFooService) {

    initializeApp() {
        // other code

        this.globalFooService.getObservable().subscribe((data) => {
            console.log('Data received', data);

Now, you just have to emit the event from some other component:

    selector: 'app-home',
    templateUrl: '',
    styleUrls: ['']
export class HomePage {

    constructor(private globalFooService: GlobalFooService) {

    onSomeButtonClick() {
            foo: 'bar'

The similar you can do for namespaced events. Checkout my blog on this for quick solution



Ugh. I get that it’s probably well-intentioned, but anybody who follows that blog is just going to end up reinventing all the flaws of Ionic Events. As for the code you posted in this thread, I would suggest anybody interested in using it:

  • get rid of any: a major benefit of using Observables here is type-checking
  • not use providedIn: 'root' because it prevents mocking
  • actually return an Observable from getObservable(), because the whole point of gating it behind a method is to prevent unexpected access through the Subject interface

@sagrawal thank you, you are right the solution by simulating the old events class with new service

1 Like

These are good points. I think the important thing to remember is that the events system that people (and I) have used up until now was extremely simple to understand and therefore use and maintain.

People don’t want to use a more (seemingly) complex way of achieving something if another does exactly the job it’s supposed to do.

I read your linked post on why events are not recommended, my rebuttal for the 2 points:

  • Typos: I have a list of events in an object so I can use them throughout e.g. myEvents.login_success: aka no typos ever.
  • Type safety: all my events are object checked at the receiving end and work fine. The code is pretty straightforward.

Just how I see it.

Shadow DOM is a classic example of this in IMHO - it brings all this lovely encapsulation benefit for web components - but then becomes a royal pain in the butthole for customising them, which is exactly what is so good and EASY about plain CSS.


Easy to start using, I’d agree, but you’ve got a steep hill to climb to convince me on “maintain”. When I come upon a new codebase (or an old one that I’ve simply forgotten all the details about) and need to add a new feature, I do my best to minimize my unwanted impact. Often the hardest part about that is figuring out what depends on what. A targeted Observable is easier to wrap my head around than a diffuse and frequently totally undocumented global Events dispatcher.

An important part of your point here is “that people have used up until now”, and that’s why I wish Events had never existed in the first place and advocated against using them years ago.

These are great ideas. I like it when my automated tools (language, compiler, IDE syntax hinting, &c) enforce things like this, though, and they can do a much better job of that with Observables than with Events. When humans have to enforce the conventions, we (OK, me at least) do a less reliable job of it. I’m curious, though, how you can “check an object at the receiving end” without using out-of-band information about the object, especially when there isn’t any checking at the sending end.

We’ve also got some selection bias going on here, because I’m primarily writing to people who want guidance about what strategies are going to make them more productive developers (note that those aren’t always the readers that I’m directly addressing). My programming style was largely forged by reading Usenet, specifically comp.lang.c, and I tried to stash away as many memories of when somebody asked “how do I X?” and somebody else would answer “here’s why you should Y instead” so that those voices would be in my head if I ever felt myself considering wanting to X.

So, with my community-forum-support-monkey-hat on, Events facilitate people who don’t know how or don’t want to go through manually setting up a safety net like you apparently have to just jump right in the ocean and write a bunch of spaghetti.

Imagine we’re having a parallel conversation about garbage collection and I say to you “who needs it? I keep a list of allocated memory blocks, and before I access any memory I make sure it hasn’t been freed”. Wouldn’t you tell me “great, but (a) you shouldn’t have to be doing all that and (b) don’t you still find accidental double disposal bugs or memory leaks”?

I see shades of this discussion in features like access control in language design. I like it. I miss it. I wish JavaScript had it. But yes, you could make the exact same argument against it: it’s a royal pain in the butthole to futz around in the innards of stuff, which is exactly what is so good and EASY about JavaScript’s “everything is just a bag of free-for-all, loosely typed junk that can all be modified freely at runtime” model.

At the end of the day, I like, use and advocate for things that I think make it harder for me to do things I will end up regretting later, on the assumption that they’ll make you more productive as well. I dunk on things and habits that I think make it easier for me to write code that I’ll hate in the future.

Thank’s a lot, the fastest way for me to map my data i newly push to what i have on my database

1 Like