Hacker News Reader

Yeah totally the opposite. I really like RxJs and used it along side my senior dev for good effect at my last perm for several years. Our junior did find it a bit tricky sometimes though (edit: I don’t mean to imply you weren’t “senior” enough, just an observation that it was a new set of concepts to learn).

We would literally never use promises because we’d become so comfortable with how we (and angular) managed the lifecycle of observables. And we never ever used a async/await after some nasty bugs in previous projects. We never started making our own operators. And I think we never really got too complex with it. RxJs marbles and learnrxjs were often consulted. But the code seemed nice and clean and reliable. Testing was more difficult and harder to understand but we got there.

We switched to using NgRx for our state quite early in the project after a brief flirtation with observable services, so that probably pushed us further down the observable route. We kept NgRx up to date and found the helper functions really nice so there wasn’t too much boilerplate. Making new selectors and integrating them into components with the async pipe is just so damn easy with NgRx and RxJs. Effects would get mildly stupid in terms of complexity and I did have a habit of hilariously writing “these were your father’s parentheses” at the end of any particularly long set of closing parens... but yeah it seemed to just work and give us relatively few bugs and none that I recall were hard to track down. It was all very smooth.

The only thing I’d ever really complain about on that project other than our build times was MSAL, which I hated with a passion.

Yes and no.

We found that rx.js is bad for coordination. I think coordination is a big part of services in angular UI's. You need to fetch some data, wait for it, ask for different thing, maybe change some state. Promises and await are great for this and especially await syntax is readable (go channels could be even better). In rx.js you had to nest multiple switchMaps for dependant queries and for state - you either produce state as a stream result or you put some `tap` or `subscribe` with `takeUntil`.

But rx.js shines with more complex user interactions - drag and drops, brushes, interactive forms (angular has nice, reactive form api). We even put some state machines inside streams, so input signals produced events. and we had `scan` operator that manipulated machine.

My personal issue with rx.js is that BehaviourSubject is leaky - you can do anything to it, and break it's property of 'always has a value'. It is nice if your service is a reactive value that you can inject and transform or render using async pipe. But you need to be careful what operators are you using on it.

> My personal issue with rx.js is that BehaviourSubject is leaky

RxJS best practice is that BehaviorSubject should be used infrequently to never, mostly as "internal plumbing" to things like building your own mini-Operators, and that they should never escape an API boundary. If you need to pass a BehaviorSubject to a consumer you always .asObservable() it and the consumer must treat it like a regular Observable (your API boundary is always Observable<T>, never Subject<T>). (BehaviorSubjects are an imperative "back door" that breaks building things the reactive way.) That's one of my biggest personal problems with the Angular core libraries is how many BehaviorSubjects leak out everywhere in that API design. EventEmitter is a big giant BehaviorSubject. The Routing APIs leak BehaviorSubjects. Angular's "Reactive" Forms leak imperative BehaviorSubjects all over the place. The bad use of BehaviorSubjects by the core libraries leaks to the rest of the Anuglar ecosystem and there are so many "Angular best practices" that are "RxJS worst practices" purely from these early API design decisions.

> We found that rx.js is bad for coordination.

RxJS is great at "coordination". It requires a different mindset. Angular is awful at helping you get into that mindset. Angular's HttpClient is especially "bad, heavy promises masquerading as Observables" which makes it hard to think of queries/API fetches as events that can return refreshed data over time (streams of fetch results), more similar to those user interactions you saw good results from. There's a lot of useful coordination operators in RxJS beyond `switchMap()` like `mergeAll()` and `concatAll()`. If you think of a stream of request events flowing into a stream of response events flowing into a state machine (possibly with a very simple, similar `scan` to your user interaction model to reduce your state over time, a little like the "redux" pattern [1]), RxJS can be brilliant for "coordination" as data arrives.

(Angular kind of sets it up to fail. With how HttpClient works. With how Async Pipe works and isn't the default.)

> or you put some `tap` or `subscribe` with `takeUntil`

This is also where Angular "best practices" and I diverge, and I think also stems from RxJS "worst practices". RxJS best practice is also to use `tap` as infrequently as possible. It's a worst chance escape hatch at best. RxJS best practice is also the `subscribe` as "late" as possible and also as infrequently as possible and that you never have a `subscribe` without an `unsubscribe` to clean up resources, including memory. (Which can be very important if you are trying to do everything the reactive way. You can move all your setup into Observables, including the setup and teardown of vanilla JS components.) The overuse of `subscribe` in Angular components seems one of the biggest obvious reasons why so much of the usage of Observables in the Angular ecosystem looks like bloated Promises. (Which is directly a bad example set by the core library's own HttpClient.) (I also think some of Angular "best practices" uses of `takeUntil` aren't great either. I was taught that Observable completion should "mean something" as it's a key event in the stream, and shutting down Observables early mean you miss later events.)

If Angular's template language took Observables directly, without needing an "async pipe", most of those manual subscribes would just vanish in an instant. Most of the needs for `ngOnInit` and `ngOnDestroy` "lifecycle events" disappear. (As Observables have lifecycle events already in subscribe/unsubscribe setup/teardown.) Angular could have not needed Zone.js at all nor its complex "Change Detector" apparatus. Angular could have done smart things in coordinating Observable observations by templates. (A lot of what React's last several major releases have been about in building its Concurrency, Suspense, and related systems out have been about among other things throttling "non-important" DOM updates together to things like requestAnimationFrame and doing very complicated work under the hood to set all that up from VDOM changes. In an Observable world you can pipe a `mergeAll()` through `debounce(0, requestAnimationFrameScheduler)` and get things like that "really easy".)

I wound up trying to encode all of my personal best practices for writing powerful, reactive components in Angular into an opinionated reusable "component framework": https://www.npmjs.com/package/angular-pharkas

I haven't yet found a good way to encode my mindset to "reactive service classes" in Angular, in part because "it feels obvious" to me and isn't really a pattern so much as a mindset, which I know it is exactly not obvious or lots of people would be doing it and Angular's ecosystem would be less full of bad examples. Probably a key place to start based on the above conversation is that I almost always wrap any calls to Angular's HttpClient in a "forever Observable". Whatever the input is to call that HTTP API, whether it is a refresh signal or some sort of other input event (Observable) hide the `switchMap()` in an Observable of results over time. Most "dependent" data streams are coordinated sometimes as simply as a `combineLatest()` and others are `scan()` reductions (even full "state machines" in some cases of those reducers). Everything is returned as Observable<T> and never any Subject<T>. Everything flows into the Components and `subscribes` are as late as possible (and these days hidden entirely away in "Pharkas" binds). Learn when to `share()` observables (or more often `shareReplay(x)`) and reuse existing Observables rather than build new ones.

I don't know how much that helps. I've been able to wring a lot of good reactive programming out of a massive Angular frontend, but I've been fighting Angular itself (and the terrible debugging/performance experience of the gross, unnecessary Zone.js), and the greater ecosystem of "Angular best practices" the whole way. Every Junior Developer with Angular experience that looks at the code for the first time generally thinks it is readable but that "it looks nothing like Angular I am used to". It's definitely not "Angular best practices" as people are learning them today.

Also, a useful related tip for removing most uses of `tap`: install `rxjs-spy`. It's great. It provides a very simple `tag('some-observable-name`)` operator that is a no-op in Production builds and in Development builds gives you a `window.spy` toolkit that lets you log events from tagged Observables (or a regex matching tagged Observable names) or even set debugger breakpoints at tags.

[1] Though I tend towards "lots of little observable streams" over combined ball of single state refiltered back into little observables like in the "proper" "redux" pattern or how tools like NgRx try to implement that in the Angular world.

Yes - totally the opposite. In fact, I think the issue with Angular is that they've not finished the work to make Angular RX-everywhere (for example, reactive components need to be manually plugged into Subjects at the moment).

With RxJS you should use it everywhere (observing state, observing component inputs, side effects etc). It's when you use it half-heartedly that you get problems with merging different programming paradigms.

The biggest issue with RxJS that we've found is that some devs have a super hard time getting to grips with the paradigm, and if your project is mostly those types of people, it will end up a disaster.

> With RxJS you should use it everywhere (observing state, observing component inputs, side effects etc). It's when you use it half-heartedly that you get problems with merging different programming paradigms

Yes, yes ,yes! I have been working with angular professionally for five years and fell in love with rxjs. If you manage to use it for everything, it really shines. Your entire codebase becomes declarative and it works beautifully. The only downside is that it takes some time to get it started up from the ground up, but once you do making changes and adding features becomes trivial. Try making smallish pipes and comment their purpose. Break them modular pieces.

On the one hand, I absolutely love working with rxjs on a fairly large angular app as a side project. It affords me the chance to be clever with code, to reason about coordinating multiple asychronous streams, and so on. Firestore gives me observables of the queries I run where the data update themselves, and the user generates events that turn into data mutations. It is all just super great.

On the other hand, I recognize that doing this well and correctly (understanding how to pipe together operators instead of creating lots of intermediate subscriptions manually, which I see a lot in example / stack overflow code) requires a high level of understanding.

It is a whole change in how you think about event pipelines and code structure. I don't think I would want to migrate my day job systems to it, because then you need everyone on the team to develop that understanding. I'm sure they _could_, but working with promises and trad event handlers is a lot simpler, as long as you keep the rest of the data / eventing pipelines simple.

I understand this paradigm within the context of stream processing, but it seems like a weird way of modeling most REST api-based web applications.

I feel like a promise-based model makes way more sense for most simple web applications. Where you have a http request and response, a promise model seems to suffice for most applications communicating via http-requests to an API layer. Modeling as a stream doesn't make sense to me, and seems like it would over-complicate an otherwise simple mental-model.

In most of the simple web-applications I have encountered there is one or more requests made to unique endpoints for data after the document response has been completed. No need for handling multiple events from the same endpoint, debouncing, multi-casting, unsubscribing, back-pressure, or whatever else. These operations seem to make way more sense in the context of stream processing.

Rx is a hot-shot, look what I can do, I am smarter than you, paradigm and not much more. Source: I did that to co-workers when I learned it.