3 ms·

This really isn't a fair statement to make because Angular without RxJS and Observables is nothing. The core http library is based on observables. If you forego

This really isn't a fair statement to make because Angular without RxJS and Observables is nothing. The core http library is based on observables. If you forego observables, you're using very little of what makes Angular useful.

paulirwin 5y ago
IMO using Observables instead of Promises for most API-type HTTP calls causes more harm than good. i.e. if you pipe the observable into an async pipe in more than one place, it does more than one HTTP call. I find in Angular code having my services that do HTTP calls return Promises via .toPromise() is much cleaner, and enables async/await and try/catch. Also with Observables, you have to remember to unsubscribe if you manually subscribe to the call, implement OnDestroy, etc. No need to worry about that with Promises. Observables are great for other things though, like debouncing input, timers, @Outputs, etc. where there might be more than one result produced. They're awkward compared to Promises for single-result futures.
- WorldMaker 5y ago
  Yeah, Angular uses RX Observables so terribly and its HTTP module in particular for using Observables as "heavy weight Promises" does so much injustice for the entire ecosystem. People using Angular treat Observable subscribe() like it is just a bad non-conforming Promise then() in nearly every project including examples baked into Angular's own awful documentation and many "Production" libraries out there. Those bad habits are just so entirely persistent across the ecosystem that you just about have to assume every dependency is a memory leak (including Angular team's own CDK and Material libraries!). I've made PRs to things to push them to use .toPromise() at least when they want Promises. I was angry for days when I finally discovered where they buried AsyncPipe in the documentation (letting the template language automatically manage subscribe/unsubscribe rather than all bad habits of every component for themself and all the boiler plate for OnDestroy). Something like that should have been the default in the template binding language, not hidden away in a closet in the basement of the documentation. But they buried it because they never really committed to RxJS in the first place (such a huge dependency to half ass) and would have to teach things like shareReplay and hot versus cold Observables if they were to recommend AsyncPipe more strongly and/or make it the default it deserves to be (if they were actually committed to RxJS/Observables). (React's been on a multi-year journey to towards Suspense/Concurrency and waiting for some updates together before scheduling them/Scheduling some DOM updates on requestAnimationFrame versus others more immediately that Angular could have done it so easily with a couple RxJS operators at template binding time if it had been intelligently designed with good defaults! It's amazing how hard they have instead worked to sabotage everything about the RxJS ecosystem in Angular.) There's too many leaky boat escape hatches from RxJS and the few core libraries that make use of RxJS make use of it so poorly as either heavy-weight Promises or heavy-weight Node Classic Event Emitters (and bleeding Subjects/BehaviorSubjects everywhere across API boundaries which are their own violations of RxJS best practices). As an RxJS fan going into Angular it just makes me weep.
y4mi 5y ago
Thats true to a degree, but the distinction makes sense to me because angular is not the only project using reactive concepts. RxJS is just one of the implementations [1] and people that haven't grokked it would struggle with other project utilizing it as well - even if its a React frontend, Go backend etc. (and as others have pointed out: angular should not be considered a poster-child of reactive programming. they made it work somehow, but its really easy to get memory leaks even if you're just copy-pasting code from the official angular docs) - [1] http://reactivex.io/languages.html http://reactivex.io/languages.html

paulirwin 5y ago

IMO using Observables instead of Promises for most API-type HTTP calls causes more harm than good. i.e. if you pipe the observable into an async pipe in more than one place, it does more than one HTTP call. I find in Angular code having my services that do HTTP calls return Promises via .toPromise() is much cleaner, and enables async/await and try/catch. Also with Observables, you have to remember to unsubscribe if you manually subscribe to the call, implement OnDestroy, etc. No need to worry about that with Promises. Observables are great for other things though, like debouncing input, timers, @Outputs, etc. where there might be more than one result produced. They're awkward compared to Promises for single-result futures.

WorldMaker 5y ago
Yeah, Angular uses RX Observables so terribly and its HTTP module in particular for using Observables as "heavy weight Promises" does so much injustice for the entire ecosystem. People using Angular treat Observable subscribe() like it is just a bad non-conforming Promise then() in nearly every project including examples baked into Angular's own awful documentation and many "Production" libraries out there. Those bad habits are just so entirely persistent across the ecosystem that you just about have to assume every dependency is a memory leak (including Angular team's own CDK and Material libraries!). I've made PRs to things to push them to use .toPromise() at least when they want Promises. I was angry for days when I finally discovered where they buried AsyncPipe in the documentation (letting the template language automatically manage subscribe/unsubscribe rather than all bad habits of every component for themself and all the boiler plate for OnDestroy). Something like that should have been the default in the template binding language, not hidden away in a closet in the basement of the documentation. But they buried it because they never really committed to RxJS in the first place (such a huge dependency to half ass) and would have to teach things like shareReplay and hot versus cold Observables if they were to recommend AsyncPipe more strongly and/or make it the default it deserves to be (if they were actually committed to RxJS/Observables). (React's been on a multi-year journey to towards Suspense/Concurrency and waiting for some updates together before scheduling them/Scheduling some DOM updates on requestAnimationFrame versus others more immediately that Angular could have done it so easily with a couple RxJS operators at template binding time if it had been intelligently designed with good defaults! It's amazing how hard they have instead worked to sabotage everything about the RxJS ecosystem in Angular.) There's too many leaky boat escape hatches from RxJS and the few core libraries that make use of RxJS make use of it so poorly as either heavy-weight Promises or heavy-weight Node Classic Event Emitters (and bleeding Subjects/BehaviorSubjects everywhere across API boundaries which are their own violations of RxJS best practices). As an RxJS fan going into Angular it just makes me weep.

y4mi 5y ago

Thats true to a degree, but the distinction makes sense to me because angular is not the only project using reactive concepts. RxJS is just one of the implementations [1] and people that haven't grokked it would struggle with other project utilizing it as well - even if its a React frontend, Go backend etc. (and as others have pointed out: angular should not be considered a poster-child of reactive programming. they made it work somehow, but its really easy to get memory leaks even if you're just copy-pasting code from the official angular docs) - [1] http://reactivex.io/languages.html http://reactivex.io/languages.html