benlesh
commented
1 year ago I do worry a little that people will expect the Observable constructor to behave similarly to the Promise constructor, in particular being executed synchronously and only once for every .then() callback.
That cat is sort of already out the the bag for more than a decade now. It's a non-issue in terms of broad understanding of the type. I know that's dismissive, so I'll try to elaborate.
However, to play devil's advocate, there are other APIs that don't quite line up with what the Promise constructor does despite having a similar "look", for example MutationObserver or ResizeObserver:
const resizeObserver = new ResizeObserver((entries) => {
// do stuff
});
resizeObserver.observe(element);
resizeObserver.disconnect();
const mutationObserver = new MutationObserver((entries) => {
// do stuff
});
mutationObserver .observe(element);
resizeObserver.disconnect();And honestly, those two APIs would have been so much better off as observables, because as they're currently implemented, while you can unobserve different elements, if you observe two different elements because you want to do something similar with each, you end up needing to add conditionals in the callback to handle them in whatever slightly different ways you might need to. As opposed to something like new MutationObservable(element).subscribe(callback) or the like.
In terms of unicast/multicast, which is this issue:
const expensiveThingObservable = new Observable((subscriber) => {
subscriber.next(someReallyExpensiveComputation());
});This is already something people face with ordinary functions:
const getExpensiveThing = (callback) => {
callback(someReallyExpensiveComputation())
}And the solution is exactly the same:
let firstTry = true
let expensiveThing = null
const getExpensiveThing = (callback) => {
if (firstTry) {
firstTry = false;
expensiveThing = someReallyExpensiveComputation();
}
return expensiveThing;
}Again, identical with an observable:
let firstTry = true
let expensiveThing = null
const expensiveThingObservable = new Observable((subscriber) => {
if (firstTry) {
firstTry = false;
expensiveThing = someReallyExpensiveComputation();
}
subscriber.next(expensiveThing);
subscriber.complete();
});Now when it's asynchronous, it's just a little different:
let waiting = true
let expensiveThing = null
let deferred = new Set()
const expensiveThingObservable = new Observable((subscriber) => {
if (waiting) {
someReallyExpensiveAsyncThing((err, value) => {
waiting = false;
expensiveThing = value;
const subscribers = Array.from(deferred);
for (const s of subscribers) {
if (err) {
s.error(err);
} else {
s.next(value);
s.complete();
}
}
})
} else {
subscriber.next(expensiveThing);
subscriber.complete();
}
});BUT: No one should be using an observable for an asynchronous single value, that's silly. Just use a promise for that. But even that comes with gotchas. For one thing, it's not an amazing idea to keep a promise around as a means of caching a value. Some promises can close over scope that is retained for the life of the promise, that's a runtime implementation thing, but it's still worth avoiding. So even with promises, the "expensive calculation" issue gets a little weird:
let promise;
let waiting = true;
let expensiveThing;
async function getExpensiveThingAsync() {
if (waiting) {
promise ??= new Promise((resolve, reject) => {
someReallyExpensiveAsyncThing((err, value) => {
waiting = false;
if (err) {
reject(err);
return;
}
expensiveThing = value;
resolve(value);
})
});
return promise;
}
return expensiveValue;
}In the end, Observable is a very low-level type, Promise is a low-level type. Neither are engineered to solve every problem, rather they are building blocks to allow such things to be built. Observable is actually a little more "low-level" than Promise in a number of ways, and could be used to implement promises (or a promise-like thing) but not the other way around.
tbondwilkinson
domenic
domfarolino
To preface, I understand that RxJS and other Observable implementations are widely used and very popular, and that a lot of people have been very successfully using Observables for very long time in many applications.
But there's a difference between using a library and using a web platform primitive. And I do worry a little that people will expect the
Observableconstructor to behave similarly to thePromiseconstructor, in particular being executed synchronously and only once for every.then()callback. Observables don't really work that way, as the callback parameter is called whensubscribeis called, an unlimited number of times. This is the much discussed cold vs hot distinction.So for example, maybe it's really easy to write:
And people comfortable with promises will think that's only going to be executed once and then each subscriber gets the expensive value, when in reality the expensive computation happens once for every subscriber.
This is less of a concern for Observables that the platform creates for something like event listeners, where the browser is in charge of the observable instantiation and the rest of the API is just really offering a better listener pattern.