4 ms·

Wouldn't this be a lot easier to understand and work with? let newScore = await fetch(url) .then(r => r.json()) .then(obj => obj.ID) I think a

Wouldn't this be a lot easier to understand and work with? let newScore = await fetch(url) .then(r => r.json()) .then(obj => obj.ID) 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.

dmitriid 7y ago
Yes, in this particular case `then` works better. Pipes are a very generic pattern though, and are quite useful when you have a chain of operations (whether those operations are async or not).
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 ago
  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.
  - 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 ago
  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.

dmitriid 7y ago

Yes, in this particular case `then` works better. Pipes are a very generic pattern though, and are quite useful when you have a chain of operations (whether those operations are async or not).

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 ago
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.
- 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 ago
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.