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.

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

[Santon-Motho]

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

[timonkrebs]

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.

[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

[dopeshots]

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

[luxiansheng]

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

[VladyslavHaidar]

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

[poh]

How do you handle change detection on window resize?

[TheSaceone]

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

[kaischonberger]

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.

[nomoredarts]

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

[brandonjoaocastillo]

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

[aravindmuthu]

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

[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...

[osph]

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

[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 :)

[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.

[urwrong]

Why can’t you slow down explain properly.. why soo hurry?