-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compare pipeline syntax operators with API function calls #273
Comments
Thanks, @sffc! (To make it clear, when I presented proposal-function-pipe-flow, I did not intend for it to be a potential supplanter of the pipe operator, but rather as an adjunct or complement for serial callbacks.) But, yes, and we definitely could call the function-API-only possibility out in the explainer, and we could make comparisons with its real-world examples. For what it’s worth, I myself did consider a world with Function.pipe only, and I checked the real-world code examples I put in the explainer. This was a while back… As far as I could tell, the answer would still generally favor the topic-style pipe operator over. For example, consider the explainer’s first example, from React v17.0.2: console.log(
chalk.dim(
`$ ${Object.keys(envars)
.map(envar =>
`${envar}=${envars[envar]}`)
.join(' ')
}`,
'node',
args.join(' '))); This is not an example where Function.pipe would particularly shine (especially given the engines’ concern about encouraging developers to allocate more throwaway closures; cf. #221): pipe(
Object.keys(envars)
.map(envar => `${envar}=${envars[envar]}`)
.join(' '),
v => `$ ${v}`,
v => chalk.dim(v, 'node', args.join(' ')),
console.log,
); …compared to topic/pipe syntax: Object.keys(envars)
.map(envar => `${envar}=${envars[envar]}`)
.join(' ')
|> `$ ${^^}`
|> chalk.dim(^^, 'node', args.join(' '))
|> console.log(^^); Having said that, it’s worth adding this possibility to the explainer as considered. I’ll mark this as a documentation to-do. |
I was excited today to see the Function.pipe/flow proposal.
I think the direction of standardizing ECMAScript APIs to solve the well-known problems of callback complexity is something that should be explored.
The Pipeline champions considered "hack style" and "F# style" options for the pipeline proposal. However, it would be useful to see a third "API style" option. In other words, take the examples that motivate the pipeline syntax operator and show how they would work with Function.pipe, Function.pipeAsync, etc.
I would note that the "API style" is already popularized by the async package on npm, so there is a deep set of prior art for this.
The text was updated successfully, but these errors were encountered: