Promises are inferior to observables for `.every` because the result may be known synchronously but is not readable synchronously #203

rbalicki2 · 2025-02-28T02:14:30Z

Promise-returning APIs are strictly inferior to observable-returning APIs

A promise cannot be synchronously read. An observable can synchronously fire events. So it's quite unfortunate that you will be unable to read the value of .every (et al) immediately, even if the value is known to be false:

const myObservable = new Observable(subscriber => subscriber.next(123))
myObservable.every(x => x !== 42).then(() => console.log('then callback'))

// yes, this isn't equivalent. I'm being quite lazy
let hasFired = false;
myObservable.subscribe({ next: x => if (x !== 42 && !hasFired) { hasFired = true; console.log('subscribe callback') } })

subscribe callback will be logged during the same tick, and then callback subsequently. This seems like a huge disincentive to using the promise-returning methods like .every, and a strong incentive to use the superior userland variant.

Is this a real-world concern?

This pattern (synchronously reading the result of an observable) is used in Relay, and I'm sure elsewhere.
In React, if you are reading data from a promise that has already resolved, you have to: throw (i.e. interrupt rendering), store the promise value elsewhere where it can be read synchronously, and re-render. That's a lot! Instead, if one used an observable, one could read the value synchronously and avoid that overhead.

An alternative

If the fact that observables are meant to be able to serve more than one event a reason to use a less performant API, I would suggest introducing a new class (OneShotObservable?) which will call next at most once, and can call it synchronously.

The text was updated successfully, but these errors were encountered:

rbalicki2 · 2025-02-28T02:31:11Z

There's some overlap with #20.

rbalicki2 changed the title ~~Promises are inferior to observables for .every, etc.~~ Promises are inferior to observables for .every because the result may be known synchronously but is not readable synchronously Feb 28, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Promises are inferior to observables for `.every` because the result may be known synchronously but is not readable synchronously #203

Promises are inferior to observables for `.every` because the result may be known synchronously but is not readable synchronously #203

Uh oh!

Promises are inferior to observables for .every because the result may be known synchronously but is not readable synchronously #203

Promises are inferior to observables for .every because the result may be known synchronously but is not readable synchronously #203

Comments

Uh oh!

Promise-returning APIs are strictly inferior to observable-returning APIs

Is this a real-world concern?

An alternative

Uh oh!

Promises are inferior to observables for `.every` because the result may be known synchronously but is not readable synchronously #203

Promises are inferior to observables for `.every` because the result may be known synchronously but is not readable synchronously #203