Re:Babel 7.5
by Klathmon on Sunday July 07, 2019 @11:20AM
(#20375510)
Wouldn't this be a lot easier to understand and work with?
I think another problem is that these are just examples that aren't necessarily representative of real-life use cases but more just try to show all the different ways of using the syntax in one small chunk.
[ Parent
| on HN ]
That example is wrapped perfectly, so it seems a bit unneeded. A more complex example would be
// helper for method calls in pipes
const _ = new Proxy({}, {get(_i, c) { return (...args) => e => e[c](...args)}})
document
.querySelectorAll('.requestedIds')
|> Array.from
|> _.map(el => fetch(`//address/${el.value}`))
|> Promise.all
|> await
|> _.map(re => re.json())
|> Object.fromEntries
|> processResponse
In this case, there is both methods and function calls, which complicates reading quite a bit. Converted to pipes, it's simply from top to bottom.But reading it like this I greatly prefer the F# style since it reads a lot more straightforward and easy to understand what is happening.
That being said, can't you abuse the promise syntax to get something very similar right now? Since `.then` will wrap a non-promise return value in a promise, this would do the same as your example:
Promise.resolve(document.querySelectorAll('.requestedIds'))
.then(p => Array.from(p))
.then(p => p.map(el => fetch(`//address/${el.value}`)))
.then(p => Promise.all(p))
.then(p => p.map(re => re.json())
.then(p => Object.fromEntries(p))
.then(p => processResponse(p))
But funnily enough, as I went to go write out that example, I realized that I have no idea what the hell is being passed into the `_.map` functions... Even me being lazy and using `p` as the variable name for each pipe, the version that writes it out is massively easier to understand in my opinion.I'd like to see the type signature of that `_` construct.
It seems to me like the bind operator would've made the extra complexity unnecessary.
_.map is basically syntatic sugar for p => p.map, only written with today's javascript capabilities. I just tried to implement the proposed #. Dynamic access to methods doesn't yield very nice type signatures.