/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 Observable
s, 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 Event
s 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 Event
s can do, Observable
s can do in a much more maintainable and error-resistant way.