brainkim
commented
4 years ago Perhaps I was being glib when I wrote that 😬. I was thinking of the RXJS operators which work on observables of observables and how incomprehensible they seemed (to me). These functions are often accompanied with wild marble diagrams like the following:
and I have yet to see a production codebase which actually uses observables of observables in a meaningful way.
These operators are trying to solve the problem of callback hell, which is when code with callbacks tends to expand into a pyramid-like structure, except this time it’s calls to pipe and subscribe which have to be flattened. I’m sure RXJS experts have got this figured out, but I bristle at the idea of using a function to concatenate two observables together, when with async iterators, concatenation is just iteration in an inner loop:
for (cons iter of iters) {
for await (const value of iter) {
console.log(value);
}
}And even when I was working with a single observable, I was never able to remember which of switchMap, flatMap, mergeMap, concatMap, etc. I needed in a specific situation. You can say that these operators solve the problem of callback hell, but I don’t see them being as effective as async/await and the yield* operators, if only because async/await/yield are actual language features.
Is there something that you can write with repeaters that you cannot with observables?
Let me do you one better and point out something you can write with observables that you cannot with async iterators: you cannot synchronously dispatch updates using async iterators. For instance, when you subscribe to a BehaviorSubject, you can be assured that when you call next on the subject, all subscription functions will fire synchronously:
const subject = new BehaviorSubject(0);
subject.subscribe(console.log);
subject.next(1);
console.log("a");
subject.next(2);
console.log("b");
// => 1, "a", 2, "b"Callback-based APIs have the advantage that the callback can be run synchronously when data updates, whereas async iterators are asynchronous on both ends, so that if you have a shared mutable data structure like the DOM, its state can change between when you push data into the async iterator and when you pull data from the iterator. In this way, async iterators are bad at describing the “current” state of some shared data, and I‘ve run into race conditions when trying to use async iterators in this manner.
However, if you need exactly synchronous dispatch, it’s my belief that observables are too high-level an abstraction anyways, and you’re much better off using something like an EventTarget with dispatchEvent or something like a MutationObserver where you can call takeRecords when you need to. Observables are stuck in a middle-ground where their high-level use-cases are better solved by async iterators because async iterators have language-level support, and low-level use-cases are better solved by one of the many other callback-based APIs which are already available in javascript.
I can think about backpressure as a possible candidate
I think you are correct in pointing out that backpressure is an important feature of async iterators which observables are unable to replicate. Most observable solutions do not solve the fundamental problem of backpressure, i.e. what to do when producers produce values faster than consumers consume them, and simply defer the problem further downstream to later consumers. You can think of observables and async iterators as a series of connected pipes, and all observables do to deal with backpressure is to let a certain pipe or joint leak, or hang a bucket from a specific pipe. This means that if the flow is too strong, there still can be problems further down the pipeline. Async iterators can emulate the solutions observables provide but also can do something observables cannot, which is to slow down producers, which in the above analogy would be to tighten the spigot which leads into the house or something.
This stackoverflow answer goes into more detail about the differences between observables and async iterators, and I encourage you read it if you haven’t already. Essentially, repeaters are the glue code which converts “push-based” APIs to “pull-based” async iterator API.
Also, you say “aside from developer experience,” but I’ve found that async iterators are just fun to work with, producing elegant and readable code. Give async iterators (and maybe repeaters 😇) a try for a week in a small, isolated part of your codebase. I guarantee the code which you create will be easier to read, maintain and explain. I look forward to finding new patterns (and perhaps even frameworks!) based on async iteration, because I think it’s one of the coolest and underused features of modern javascript.
brucou
The authors of observable articles do elaborate mental contortions to shoehorn observables into the bottom right corner, when the most analogous data structure is undisputedly async iterators.
I am reviewing the library, and running thruogh the documentation, I came across this:
I have been using observables for a while and I wonder what you meant by callback hell occurring also with observables. Do you have an example? If by higher-order observable operators, you meant
flatMaporswitchMapand the likes, I have actually been using those pretty often, and I would disagree that they are incomprehensible to human beings. That is quite a strong statement.Aside from developer experience, I guess my next question is: is there something that you can write with repeaters that you cannot with observables? Or to say the same, are repeaters more expressive than observables? I can think about backpressure as a possible candidate, but I haven't been able to figure the answer from the documentation to figure that out so asking here.
Thanks!!