Edit: magic-promises promotes all accessed properties to magic-promises as well, and performs magic on functions, so it's not exactly the same, but I'm not sure if I'd want to add the proxy overhead to my code just to make my code more "fluent".
As explained .text() returns a promise, and the fact that many people don't know that and that your 1-line solution does not work is a strong indication that my solution is helpful!
With magic-promises you don't need to worry about whether something regurns a promise or not. See fs-array, some methods will return promises and some won't, but you can just treat them all the same.
I love it when articles just put statements out like "This syntax would be much better, wouldn't it?" and then just assume the answer is obviously yes and don't find the need to provide any arguments for that.
I agree, explicit is better than implicit. But redundant is worse than non-redundant. This library just provides syntax sugar to make things cleaner. There are many times that arbitrary decisions have been taken. Why cannot you wait to an array of promises? Wouldn't that be explicit and clear?
Awaiting an array of promises looks neat, but it has a (small?) caveat: you can't do the same for the non-await version. You can't do `[...].then()`.
I'm less fan of the second proposition. Imagine someone seeing that snippet on internet and copying it: he would have no way of knowing that ".text()" is actually a promise and could potentially be making more I/O calls than he thought.
It's lovely how node.js started with callback nesting hell, then to promise chaining, then to async/await, then to "magic" libraries like this.
How long since someone will figure out how to get rid of the (error-prone) await keyword, and go back full circle on plain old synchronous-style syntax?
Yes, it's a bit over-verbose than the one liner, but ergonomically it is step-by-step imperative programming just like Grandma C++ used to bake, and few would argue that it isn't readable old-fashioned ergonomics.
Promise.all is a tougher thing to get "ergonomics" from, but more often than not, a refactor to a "classic" for loop pattern is often clearer. The semantics change, unfortunately, yet more often than not the clearer "one-thing-at-a-time" of the simpler refactor is easier to debug, less harsh on called services, less pressure on client memory, and simpler to progress report.
Instead of:
const responses = await Promise.all(urls.map(url => fetch(url))
const texts = await Promise.all(responses.map(response => response.text())
for (let text of texts) {
doSomething(text)
}
Try:
for (let url of urls) {
const response = await fetch(url)
const text = await response.text()
doSomething(text)
}
Again, the semantics change: instead of waiting for all of them to complete as massively parallel it operates a bit more "synchronously" one at a time. But the benefits again are that ergonomically it is much clearer what each individual step is, how much work has been done, roughly how much work is left to do. Additionally, you aren't creating a massive array of the text of every response before operating on each text, which can be a big deal for performance memory pressure. More often than not, I've seen cases where the simpler for (let of)/await pattern here is more performant than all the parallel calls simply because of the drop in this memory pressure.
For cases where you do need more of the parallelism, ESNext AsyncIterable is a better plan than Promise.all(), and affords the for-await pattern:
for await (let response of responsePromiseIterator) {
const text = await response.text()
doSomething(text)
}
Which again, is more ergonomic overall, often easier to get the performance right than Promise.all(), and easy enough to change to different parallel strategies because the code stays the same regardless of the scheduler used to build your async iterator.
Exploring the reasons why I launched a library to improve async-heavy workflows which falls back to normal promises. It is very useful specially for tool authors, see the library I also published recently `fs-array` using `magic-promises`.
Promises were a giant mistake. How many times have you had a programming error (TypeError, ReferenceError, etc.) suppressed by your operational error handling code?
Solves what problem? The article is about some very minor syntax sugar, while you are plugging a tangentially related library with a whole raft of its own abstractions. I’m struggling to understand the context here.
Suggesting RxJS in this context IMO is like when someone suggests doing `const $ = sel => [...document.querySelectorAll(sel)];` as helpful syntax sugar for the 20-lines of JS project but they get shut down because it's no React.
Example:
[1] http://vanilla-js.com/Edit: magic-promises promotes all accessed properties to magic-promises as well, and performs magic on functions, so it's not exactly the same, but I'm not sure if I'd want to add the proxy overhead to my code just to make my code more "fluent".