Pipeline operator -> syntax sugar for Promise.then?

[simov]

TBH I haven't read through all of the proposals, issues, and comments, so excuse me for that, but for the past 3 years I've been using this little helper:

var compose = (...fns) => (args) =>
  fns.reduce((p, f) => p.then(f), Promise.resolve(args))

and I've always thought that the pipeline operator should be merely a syntax sugar for Promise.then.

That's how I've built my own http client, and also used it in many other projects, but here is an example of a bigger pipeline as well.

So again I've always thought that the pipeline operator should only be helping me with getting rid of the initial step of composing the pipeline:

var {res, body} = await compose(
  Request.defaults({headers: {'user-agent': 'request-compose'}}),
  Request.url('https://api.github.com/users/simov'),
  Request.send(),
  Response.buffer(),
  Response.string(),
  Response.parse(),
)()

and thus make it as:

var {res, body} = await
     Request.defaults({headers: {'user-agent': 'request-compose'}})
  |> Request.url('https://api.github.com/users/simov')
  |> Request.send()
  |> Response.buffer()
  |> Response.string()
  |> Response.parse()

similar to what was done for Promises and async/await back then.

Partial application and having to await things there is not a problem:

var sum = compose(
  (x) => x + 1,
  (x) => new Promise((resolve) => setTimeout(() => resolve(x + 2), 1000)),
  (x) => x + 3,
  async (x) => (await x) + 4
)
await sum(5) // 15 (after one second)

because things are being awaited always:

var sum = await 5 // 15 (after one second)
  |> (x) => x + 1
  |> (x) => new Promise((resolve) => setTimeout(() => resolve(x + 2), 1000))
  |> (x) => x + 3
  |> async (x) => (await x) + 4

which is the only downside, but unless you are chaining thousands of Promises it's fine.

[casey-chow]

I have a similar system set up in my code and it certainly gets the job done! I think there's two issues with the approach though:

1. What should you do with objects that are then-able but you don't want to resolve them as a promise? Or want to work with the promise object itself?
2. What should you do if you want to use the pipe operator but are working within a non-async context?

I don't really see a way around an explicit await construct because of the first issue--there's a lot of libraries out there that overload promises in this way, not to mention that implicitly await-ing everything, while convenient, also makes it more difficult to understand the behavior of the application.

[simov]

About point 1. that means that you will have to call your pipeline, rather than executing it. Meaning, if you have a sub pipeline in a module, for example, you just have to wrap it up in a function.

About point 2. that's a valid point, but from my experience people are decorating their functions with async all the time, even if that function doesn't have any asynchronous logic in it.

So we are at this point where everyone is using async/await all day, but quite a few developers doesn't even know anything about promises. The way I'm seeing the pipe operator fitting into this is simply by surfacing up the idea that you can compose your promises, which we do have right now, but no one is using it. If we set it up that way, then there is nothing to understand further, you are simply returning a value, and you can have asynchronous logic if needed.

[theScottyJam]

It's one thing if some developers are decorating their functions with async, when they shouldn't be, and it's quite another if we start encouraging that. There's a lot of reasons why this shouldn't be done.

For one, Javascript will cause any code with an await (implicit or explicit) to actually wait at least one microtask before continuing execution. Code full of unnecessary async/await will be unnecessarily slow.

Another reason is that I would be unable to refactor any chunk of synchronous code to use this pipeline operator (which implicitly awaits) without forcing everyone who's using my function to await it - which is especially bad if I'm creating a third-party library, as that would be a breaking change. This would basically render the pipeline operator unusable to anyone creating a third-party library that only does synchronous logic.

[simov]

That's true, and what I was outlining above was only a compromise. Pipeline operator proposal has been stuck forever at this point, and from what I know support for await was the problem initially. We can't go with a pipeline operator without support for asynchronous logic either, as it will be as equally unusable.

[theScottyJam]

The "await" thing is certainly an issue - but I was under the impression that the current holdup was simply some TC39 members being unsure if the new syntax is actually useful enough to warrant adding it to the language (though someone can correct me if I'm wrong here). There's generally a lot of hesitance when it comes to adding syntax to the language, which is a good thing, adding syntax left and right will create an over-bloated and difficult to learn language.

Also, promises already have a way of doing pipelining - it's just slightly more verbose.

Compare this:

const result = await doAsyncTask()
  .then(x => anotherAsyncTask(x))
  .then(x => andYetAnotherTask(x))

with this:

const result = await doAsyncTask()
  |> await anotherAsyncTask(?)
  |> await andYetAnotherTask(?)

pipelines certainly help make to make async code a little nicer, but not enough to warrant its own syntax. The pipeline operator provides the most value to sync code (or mostly sync code, with the occasional await in the middle).

[simov]

The pipeline operator provides the most value to sync code (or mostly sync code, with the occasional await in the middle).

I disagree with that. Almost all of the JavaScript code on the server or serverless if you will, have to deal with asynchronous operations. And literally no one is using Promise.then, see my first comment about that. Having pipes can help pushing that pattern into the mainstream. The truth is a lot of today's JavaScript developers know almost nothing about the language.

[theScottyJam]

Almost all of the JavaScript code on the server or serverless if you will, have to deal with asynchronous operations.

Yes, a lot of Javascript runs in async environments, but most written code is still doing synchronous tasks. Have you ever made a helper function to parse data from a string? To reshape data that some server provided to you? These would all be synchronous helper functions (even if they're being used on a server) that would benefit from a pipeline operator. Have you ever used a library such as underscore? Wouldn't you find it fishy if you had to "await" each time you called one of their functions - and it turns out the only reason the await was needed, was because lodash wanted to use the pipeline operator?

The truth is a lot of today's JavaScript developers know almost nothing about the language.

That's fine, and it's important to keep that in mind. But ... these people are also learning. Instead of trying to hide important parts of the language from them, it would be better to teach these parts to them, when the time is right. Promises are a very important part of the language - async/await allows people to hide a lot of the details of promises away in many scenarios, but it can never fully hide them, and sooner or later these newer programmers need to understand them to be effective at asynchronous programming.

And literally no one is using Promise.then

Maybe that's what you've seen in your experience, I've certainly seen many people who still like to use Promise.then - there are times where it makes for cleaner code than await does. This is one of those scenarios. If some asynchronous task reads better when written as a pipeline, why not just use .then() - it's what it's for. The introduction of async/await was never meant to cause the community to shun .then() and .catch(), and if you choose to embrace promises instead of shunning them, then you can immediately start reaping the benefits of asynchronous pipelining too, among other things.

The whole point you seem to be making is that "promises are confusing, especially to newcomers - better to just make all functions async and provide language constructs to help people pretend they're not a thing". This is not really a reasonable request - we can't just have people making all of their functions async, plus, this flies against a lot of the ideology behind promises and async/await. It would be better to view promises as a useful tool that newcomers can learn and utilize one day, when they're ready. Many language features fall into this category - just because it might not be newcommer friendly does not mean it's bad or useless - maybe it shouldn't be used in a project where you expect a lot of newcommers to contribute to it (maybe that's the type of project you're often working on), but not all projects are like that, and sometimes these more advance language features are the only things that can keep the code clean, fast, and organized.

Another way to put it - you can't avoid promises because they're confusing, then wish you had an async pipelining available to you. That's exactly what promises do. It's not considered bad practice to use them either, you've just personally chosen to not use them to their full potential. There's really not any incentive to add another way to do asynchronous-only pipelining into the language when it already exists.

(Sorry, this got a bit long - I ramble sometimes)

[simov]

I can't say I disagree, but at the same time this is a 'reasonable' way to unstuck this proposal, with its own downsides. Because all else failed for the past 3 years, correct me if I'm wrong.

And again, just to clarify - using Promise.then because it's there instead of pipe operator is not a solution for me, using |> await .. seems equally as bad, contrary to the idea of composing functions.

Probably if you put await in front of the pipeline it can be treated as Promise.then and otherwise as synchronous code? The pipelines that I'm talking about are much higher level then simply transforming a string for example.

[hax]

I don't think the proposal was stucked because of async issue.

[nicolo-ribaudo]

There is also this proposal which adds syntax sugar for .then in member expressions: https://github.com/tc39/proposal-wavy-dot

[simov]

async/await was definitely an unresolved issue even 3 years ago when the rest of the spec was sort of fleshed out. On top of that even if we have something like |> await I'd argue that's not ergonomic enough.

With a simple one line wrapper (mentioned above) today we have:

var sum = compose(
    (x) => x + 1
  , (x) => new Promise((resolve) => setTimeout(() => resolve(x + 2), 1000))
  , (x) => x + 3
  , async (x) => (await x) + 4
)
await sum(5) // 15 (after one second)

So the pipeline operator for asynchronous operations have to be at least as ergonomic as the above code.

Probably one way to do it is by using a special operator at the beginning of the pipeline signifying that the first level of the following pipeline operators will be treated as a Promise chain basically.

Having a special pipeline operator for asynchronous calls along the pipeline may be another option too.

[tabatkins]

The proposal has advanced to stage 2 with the Hack-style syntax, so I'm closing this issue. You can use await in pipe bodies just like in any other expression context, so pipelines are async-friendly by default.

(That said, extending the idea of piping to handle more advanced functor/monadic cases is a very interesting direction to pursue for the future. Mapping a pipe body over an array, chaining it across Results, etc...)

[luncheon]

The proposal has advanced to stage 2 with the Hack-style syntax, so I'm closing this issue. You can use await in pipe bodies just like in any other expression context, so pipelines are async-friendly by default.

I think what discussed in this issue is a new wavy-dot-like pipeline operator that returns Promise.

const [user1, user2] = [
  fetch('/api/v1/user/1') -> ^.json() -> new User(^),
  fetch('/api/v1/user/2') -> ^.json() -> new User(^),
] |> await Promise.all(^)

await in Hack-style syntax seems to wait on the fly and return the result instead of a Promise, so it does not seem to be an alternative.

If this discussion has ended with the conclusion that using then is satisfactory, that's fine.

const [user1, user2] = [
  fetch('/api/v1/user/1').then(res => res.json()).then(json => new User(json)),
  fetch('/api/v1/user/2').then(res => res.json()).then(json => new User(json)),
] |> await Promise.all(^)

[ljharb]

@luncheon that's a different proposal, https://github.com/tc39/proposal-wavy-dot