The Biggest Misconception of PROMISES vs OBSERVABLES

The difference between promises and observables is often framed as a matter of having to deal with a single value or multiple values over time. But, what goes unnoticed is that many of the things we think of as being just a "single value" actually are values that change over time.
Get weekly content and tips exclusive to my newsletter: mobirony.ck.page/4a331b9076
Learn Angular with Ionic: ionicstart.com
0:00 Introduction
0:10 The Difference Between Promises and Observables
1:24 Really just a "single" value?
2:44 Dealing with values over time
3:10 Why care?
#promises #observables #js
- More tutorials: eliteionic.com
- Follow me on Twitter: / joshuamorony

[@JoshuaMorony]

New newsletter goes out tomorrow with a tip about signal effects: mobirony.ck.page/4a331b9076 (you can also get access to the complete archive of previous tips)

[@Santon-Motho]

Joshua "I am going to find every possible angle from which to speak about observables" Morony.

[@Santon-Motho]

PS: I love your channel lol

[@JoshuaMorony]

I like observables

[@orterves]

Resistance is futile. You will be Observed.

[@yousafwazir3167]

Love the videos

[@osph5525]

“Simplicity is the ultimate sophistication.” - Leonardo da Vinci.

[@Hariharan0606]

Amazing example!

[@d.nazaratiy]

"Cancellation is much easier with observables than with promises" and then you show a code that do NOT cancel anything for observable: your request is STILL happening. you just missing its result and I wouldn't call it "cancellation" since you still can ignore almost the same way with promise. The biggest misconception of promises vs observables is when people try compare them. These are TWO DIFFERENT conceptions: promise is a mechanism to EXECUTE a singular ASYNC OPERATION while observable is a mechanism to constantly MONITOR CHANGES. That's it. And you have to always think about your architecture before coding instead of blindly use some kind of silver bullet that you just learn. This is a way to deal with misconceptions in general: figure out what your code supposed to achieve, what flow it supposed to follow and only start coding after you know what you should code

[@JoshuaMorony]

This video isn't to present observables as a silver bullet. I agree with the general idea of promises being suited to a single async operation, and an observable multiple. The key point I am trying to make is that what some people see as being just a single request suited to promises, is often actually multiple requests if you consider the lifetime of the data in the application, which is something that suits the observable paradigm well. People often see observables as only being suited to esoteric/bizarre/rare circumstances, my point is that they can be useful for much more mundane situations where people often see promises as the only obvious answer. EDIT: And to your specific point about cancellation, in the case of Angular's HttpClient (Angular is usually the context for my videos) the underlying request is cancelled, but I can concede that's sort of "cheating" in this context since a separate library is handling the cancelling - the inclusion of this probably just detracts from the point of the video

[@d.nazaratiy]

@@JoshuaMoronyyou still don't get it: observables are for MONITOR changes, but not EXECUTE multiple blah-blah-blah. You should not compare these two concepts. They are different. It's like compare yellow and sweet - you can work on your dish based on idea that it should be sweet(your app main idea is a flow of async calls - promises) or that it should be yellow (your app main idea is not a flow but atomic reactions on state changes and events - observables) or you can combine them. But they are two different non-comparable and non-conflicting concepts. And when you are talking about observables as it is something to execute multiple calls - it is like saying that your dish tastes yellow. It makes no sense

[@JoshuaMorony]

​@@d.nazaratiy perhaps I don't get the distinction you are making here - in the terminology you are using I would say an observable "monitors" changes over time, e.g. the value for a page number changing, and then reacts to that change by "executing" the appropriate request (e.g. via switchMap), which allows for the code to be declarative. You can do the same thing with a promise, but not declaratively as it doesn't have this ability to observe/react to changes over time, it only perform the "execute" part which has to be triggered imperatively somewhere

[@poh9044]

How do you handle change detection on window resize?

[@dopeshots9687]

Josh. What is the difference bw RxJS and RxAngular. where should we use RxAngular

[@jonathangamble]

It would be interesting to see what you would do on the server. Most modern apps fetch on server for speed, simplified client js, and seo. Even with Universal or Analog...

[@JoshuaMorony]

I'm super keen to give Analog a go, but all the server stuff I am doing at the moment you may be pleased to know is with SvelteKit - but I am just generating a bunch of static sites and there is very little state involved so I haven't really got to explore more complex data flows in this context.

[@timonkrebs5576]

Great Video. Do you see any "valid" usecases for promise that would not be better with observables? I think the readability of async await is still better in some cases. But having two concepts that can do the same while one is a lot more powerful is not really a good place to be. For simple things i would still prefer promises maybe combined with signals... I would like to have a solution that does not require the subscription handling with the readability of async await. I am still not sure if signals operators could be that.

[@JoshuaMorony]

I'm not like anti-promises or anything - but I do generally find I almost never use async/await in the Angular codebases I have control over. On the other hand, in code bases that are not so declarative that I work in I use async/await quite liberally. I think the declarative aspect is the key point, and where having everything as streams over promises becomes more useful.

[@timonkrebs6978]

​@@JoshuaMoronyI agree completely. I almost never use Promises in Angular. But I feel like there must be an even better way to do things than rxjs. The biggest issue is having to handle subscriptions. I really hope we can find a way to make the idea of Mike Pearson for signal operators work in Angular.

[@TheSaceone]

do you have an old-fashioned standard tutorial on how to import and use signals in ionic?

[@JoshuaMorony]

There isn't anything special about using signals in Ionic, you would just import 'signal' from Angular as normal - is there anything particular you wanted to know?

[@user-hd8dm5ur3i]

@JoshuaMorony Nice content! Can we expect some ionic staff in nearest future?

[@JoshuaMorony]

I generally try to keep things generic since Angular stuff applies to Ionic anyway - is there any Ionic specific stuff you want to see?

[@user-hd8dm5ur3i]

​@@JoshuaMoronywhat I'm thinking, it would be good if we can build atleast simple ionic app with crud of course, including some interesting native or custom behavior for add/edit/delete items. There can be added interesting behavior for reload component data using ionic progress-bar/skeleton/maybe refresher. And also with some page navigation using ion-router (because we can use just angular router, but it's interesting to know how to combine them properly and cases when we should do it). Andl also we can do all of it with state (maybe custom service, maybe ngrx and others, maybe signals). What do you think? I guess it will be interesting for all the auditory

[@luxiansheng2268]

Nice perspective, how do you handle the endless call stack issue when debugging rxjs? Hard to find the triggers when debugging

[@e-jarod4110]

Not a problem because you never need to debug the built-in library You just need to debug your function

[@luxiansheng2268]

@@e-jarod4110 The problem is that I don't know who triggered my function. For example, it sent an incorrect param to my function.

[@nomoredarts8918]

To make it even more declarative I highly recommend using point free style, so switchMap(a => doSomething(a)) becomes switchMap(doSomething)

[@kaischonberger97]

Another great example why Observables can make a lot of sense for HTTP requests is the implementation of a stale-while-revalidate cache. Imagine implementing a function that returns a stale value from a cache for quick rendering and then after that returns the fresh value from the API. Ugly to implement with Promises, but so easy with Observables.

[@aravindmuthu5748]

Well observables still technically call the http request multiple times(look at the network tab) to the server each time any sort of change happens. Observable acts as an interface that communicates with the network and state of application, which is quite useful in large scale applications as well as small ones. The problem is that Rx creates a kind of vendor lock inside the application and the integration with Angular just compounds the problem Edit: I would personally find Observables useful if a state change triggers a cascading domino effect like situation, where a single api call results in a bunch of other api's being triggered, each trying to work in a sequential format, but in most cases I can simply use .then().catch() as it is way more explicit and self contained Finally: Before finishing off, I would conclude with key points: 1) If you're using Angular, use Rxjs 2) If you're using anything else, choose wisely

[@JoshuaMorony]

I'm not sure if I'm missing your point, but I expect the observable to result in multiple requests. The issue I was pointing out with promises wasn't that it makes multiple requests, it was that when taken in the context of all the requests, this is basically tackling the same problem observables are - dealing with multiple requests over time. As for vendor lock in, I've never really had too much of a concern with being dependent on RxJS, but there are currently moves underway to potentially get some kind of observable baked into the browser, which would be cool (obviously not with all of RxJS's gizmos, but it would still be good)

[@martinledoux594]

I'd hardly compare using an open source library like RxJS to "vendor lock-in". Yes, it's a good choice (almost already made for you) if you're using Angular, but you can use it with any framework or plain JavaScript. A couple years ago I heard a podcast that mentioned that 5+ years ago, the RxJS conference was almost entirely Angular people. But then 3ish years ago, that shifted to being nearly 50/50 with React developers. In that case, React developers have a lot of choice, and I'd suggest that using RxJS is a great choice - a wise one at that!

[@martinledoux594]

As for your Edit, that scenario is exactly what makes RxJS so powerful, when dealing with REST APIs. Make a single (re-usable) Observable that starts with a base-API call, which can then be switchMap()ed to a zip() or combineLatest() to make a bunch of follow-up (dependent) API requests using a value retrieved in the first request as a parameter to the subsequent requests. Yes, you can surely write a function that returns a new Promise (deferred) and chain some .then()s together like an RxJS .pipe(), and that would be just as reusable.

[@brandonjoaocastillo7490]

Can you please give the name of your theme!???

[@JoshuaMorony]

I'm using Gruvbox

[@Alex-bc3xe]

In angular I do argue always use observables is see no point not doing so.

[@AngeloMichel]

This 'comparisson' is a bit unfair imo... they omit all the boiletplate code from the observable side. In any real world situation you'd use frameworks OR make your own utlity wether or not you're using observables or promises. In fact, in real world examples you have to deal with both senior AND junior developers, which makes it FAR easier to just use javascript (or ts, ofc) because its just more simple to understand. Specially if you're just making a fetcher for a page on some client (like the given example from the video). - So yeah, when in my personal opinion Observables really shine is with let's say... handling a stream of events, or.. handling and converting events or data over time. So in short, remove the abortcontroller, in favor of any framework which abstracts this and the right-side example would be shorter and easier to read and maintain. No need to carefully read if someone used a BehaviourSubject (or if that is even the correct one to use), and this video would have a far different tone I guess :)

[@JoshuaMorony]

I think the comparisons were probably a bad idea for this video as it detracts from the main point anyway - the main point I am trying to make which you touch upon "handling streams of events, or... handling and converting events or data over time" - this is how I treat these sorts of HTTP requests in my application. People often ask why you would ever want to use an observable to handle an HTTP request that just returns a single value, my point is that when you consider the lifetime of the application those requests are often performed multiple times (e.g. you might just get the data for the current page now, but later you will run that request again to get the next page of data), so they essentially are streams of data over time which is what observables are good at handling, and specifically they allow you to write the code declaratively

[@DhainautRaphael]

@JoshuaMorony Thank you very much for this comment, The chosen example is excellent because it is indeed a fundamental question on why to adopt observables / Rxjs within an application. I never really understood the point of managing 'a single response' with observables. I now understand your point of view better and how you “design/build” an application in your mind. Ultimately, it is a question of “paradigm”. With Rxjs, you manage "interactions" as a flow/event to which your code reacts instead of declaring a "sequential approach" (I say sequential here because when we use the async/await syntax we 'flatten' the sequence of 'execution).

[@anasouardini]

The example you give only need a layer of abstraction to be added and for the unnecessary "async" functions to have a sync version (stupid browsers). This is a really bad comparison between promises and observables. You remind me of people quitting the use of Linux because modifying kernel is troublesome: promises can be improved to cover more of what observables can do.