How to Avoid Observables in Angular

Michael Hladky on October 16, 2019

Angular is an object-oriented framework. Even if there are a lot of things imperatively implemented, some services, and therefore also some third ... [Read Full]
markdown guide

Seems like an anti-pattern to go out of your way to avoid using observables with Angular and there doesnโ€™t appear to be any strong benefit in doing so other than laziness in learning something new.


Why would you want to avoid functional programming? ๐Ÿค”
It seems like Angular is not the appropriate framework for you then.


Not sure i would put Angular in the functional programming camp based on how it is used, classes for components etc.

But it becomes a lot more to use if you mix FP into it tho. :D


I'm a big fan of react, and it happens that I've been working with angular for more than two years now (you can't always choose ๐Ÿ˜… ).

At first, I've hated Observable because I was not able to understand and works with it, and also because frankly the documentation is not for beginners. Took me around 1 year to master and use Observable with ease.

I've tried mostly all the things written in this article and also read a lot of things, like "functional programming with angular", "store pattern in angular", and now "avoid observable in angular".

But please, if you don't like Observable or OOP, then angular is probably not for you, just use something else.

Tweaking, in my experience, always results into a mess.


nice article. Think you have a little typo

this.result = this.http.get('https://api.github.com/users/ReactiveX')
      .subscribe((user: any) => this.result = user.login);

result would be assigned the subscription, even though you later override it in the subscribe(). I think you mean this:

      .subscribe((user: any) => this.result = user.login);

One more logical thing I would rethink: mentioning where to subscribe: ngOnchanges and ...Check hooks are bad places to subscribe since to create onbservabke every time they are called


Good article, Michal. I would only suggest a modification in the title because it sounds pretty confusing. Juniors tend to confuse Observables (object) with RxJS (library) and reactive programming (paradigm). Thus it's quite easy for people that read titles upfront to digest the content based on such statement.

The fact is because the Observable object is not avoided at all. They are assigned to the class variables in all examples, what we may consider that they still are in use. Only the subscription is avoided to be directly used in the component implementation.


How about just do it like this :
Async foo()
This.user = await observable.pipe(take(1)).toPromise();
// this.user.id works here


Great poin.

I was going to say:
What about ChangeDetectionStrategy OnPush? We should only throw it in the trash?
We can see that you are doing it really wrong not caring about CPU and digest cicles.
Did you ever write any component, with good performance, that handles a lot of events (click, scroll) without using rxjs and OnPush strategy?
This does not make any sense IMO.
Please, study about OnPush and Async pipe instead of trying to creat such approach.
But you showed a lot of edges of Reactive Programming that takes a lot of time to understand and use with easy.



Epic! ๐Ÿ˜ I totally agree with you and based on my experience I do confirm that avoiding frp leads to messy code which is hard to reason about. Unfortunately most companies simply wants to get work done asap and do not care about maintenence. Local dev heroes create non frp code which makes adding new features like playing a jenga tower game ๐Ÿ˜ one question which I already as asked you during workshop in Warsaw (but the answer was to subscribe which is in contrary to the art ๐Ÿ˜):
How to handle the scenrio: land on the details page and want to create a form and further submit it. Form group is easy to create in a reactive way but upon submission I need the entity id which is kept in the activated route observable. Any idea how to get it without subscribe? ๐Ÿ˜Š


Lol. Old reverse "IMO, don't do this" right at the end. I strongly agree. One thing not considered is the race conditions you create when you try to do logic on things you've pulled out of observables.

Might want to lead with the fact that this is a bit of an anti-pattern.


I love the comparisons of different techniques, this gives me a much better feel for the fundamentals of observables overall.

Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

Fucking meaningless guide. Why would you be in such a situation that you don't need to use observables?

code of conduct - report abuse