3 ms·
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(
by ulucs 7y ago
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.
- spion 7y agoI'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.
- ulucs 7y ago_.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.
- Klathmon 7y agoBut 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.