Sure, it’s possible to use Observables as a drop-in replacement for Events, and your implementation isn’t terrible, but how about taking this as an opportunity to rethink the design to take advantage of the more expressive potential that Observables provide?
Especially given the example you’ve posted here of “form refresh”, this idiom sounds like a way to implement what appears to be the larger goal of “have a single source of truth for business objects, with all changes to it propagated to any components that present them to the user”.
I don’t know if the following applies to you, but it sure did to me, and took me about a year of banging my head consistently against a wall when I started with Ionic:
I am a systems programmer, having written a bunch of imperative stuff in C/C++/Pascal, even all the way back to PowerPC, 68000, and 6502 assembly and machine language. So my go-to mindset was always “how do I make X happen” or “how do I tell Y to do Z?”. I still hear questions in this vein every day here in these forums, and remain firmly convinced that the proper answer to them, while probably frustrating to the questioner in the short term, is “change your entire way of looking at the world”.
Web apps aren’t imperative, they’re reactive, and your EventService, as I see it, is an attempt to use a reactive language to try to say imperative things, which (at least in my experience) results in Vogon poetry.
Mobile apps (web apps in general) tend to have two primary purposes: (A) to present information that can often change in unpredictable ways to a user, and (B) to convey information from the user to some external place (even if that just constitutes “remembering” that information for later).
Action-at-a-distance introduces orders of magnitude of complexity in testing and debugging and opportunities for unforseen interaction problems in apps, so I believe it’s best to both minimize how much it’s done and make it targeted as precisely as possible. Instead of “hey everybody, refresh your form”, maybe things can be restated as either the type A idiom described in the earlier link, or as a type B idiom that also doesn’t require an event. Say a user presses a refresh button. The click handler for that button, instead of firing an event off into the void, would be much better served first finding the single source of truth that is stale, and then calling a refresh method in it. DI is perfect for the first part of that, which is the only hard part, as then all one has to say is injectedService.refresh().
So sorry for the wall of text, but maybe it will inspire you (or some other poor sap who bothered to read this far) to rearchitect the app so that nobody would ever know that Events once lived there.