This proposal has been languishing for years and years. I'm not sure when it last made progress, but I remember waiting for it with anticipation around 2018
Pipe Operator (|>) For JavaScript
101–110 of 437 posts
Re: Pipe Operator (|>) For JavaScript
#102Can't wait for this. Pipes are awesome in Elixir and bringing them to JS/TS will be great. To me this is both concise and readable: const weather = `https://api.weather.gov/gridpoints/TOP/31,80/forecast` |> await fetch(%) |> await %.json() |> %.properties.periods[0]
Uncaught TypeError: Cannot read properties of undefined (reading 'periods')
:3,$s/\./?./g
Re: Pipe Operator (|>) For JavaScript
#103This just complicates things if you have any kind of complex nesting.
Something "simple" like:
a(b(),c(),d(e(),f(g())))
value |> b() |> a( %, c() , v2 |> e() |> d(%, v1 |> g() |> f(%) ))Re: Pipe Operator (|>) For JavaScript
#104I love the pipe operator in Elixir!
I love the pipe operator in OCaml!
I wrote this line for a compilers class:
let _ = apply_effects effs in ()
in m |> fetch |> decode_execute |> memory_writeback
Re: Pipe Operator (|>) For JavaScript
#105Earlier quoted context omitted.
The current JS one isn't as nice as the Elixir one, at least it wasn't when I tried using it via Babel a couple yrs ago.
The JS one does seem to have some more power than the Elixir one. For instance, in Elixir, if it's a bit kludgy to pipe to a second or third argument. I find this often when I want to insert into a map. You can always define more functions, but otherwise it's annoying, because you end up with something like computation() |> &(Map.put(my_map, key, &1)).() That said, with this less-power, you do kind of end up forced t…
Pipes work really well with named arguments and partial-application. Both functionalities make it easy to get the unary function you want with minimal cruft. Lambdas solve the more complex case.
In Ocaml, you often end up doing things like:
List.create 0 3
|> List.map ~f:(fun x -> x+1)
|> List.fold ~init:0 ~f:(fun acc x -> x+acc)
|> Stdio.print_endline "%d"
Re: Pipe Operator (|>) For JavaScript
#106Can't wait for this. Pipes are awesome in Elixir and bringing them to JS/TS will be great. To me this is both concise and readable: const weather = `https://api.weather.gov/gridpoints/TOP/31,80/forecast` |> await fetch(%) |> await %.json() |> %.properties.periods[0]
It’s pretty great in R too
Re: Pipe Operator (|>) For JavaScript
#107Is this: Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') |> `$ ${%}` |> chalk.dim(%, 'node', args.join(' ')) |> console.log(%); Really better than: console.log(chalk.dim( `$ ${Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') }`, 'node', args.join(' ') )); That's the real-world example they have (I reformatted the second one slightly, because it looks better to me). N…
I won't speak about the specifics of the chosen syntax (Hack/F#) but in general - absolutely.
With pipes you can visually follow the manipulations and function calls in the order that they happen instead of being forced to scan the code inside-out & outside-in, matching parentheses and function call parameters in your head, while still visualizing intermediate results to get 1 final return value.
I find Elixir code much easier and quicker to understand, in large part thanks to its (admittedly, imperfect) pipe syntax. Code written in this way is also much easier to debug because you can quickly add `console.log`, breakpoints, or equivalent between the pipes.
I find this unnecessarily time-consuming and difficult to parse and I'd likely raise some flags in a code review:
console.log(chalk.dim(
`$ ${Object.keys(envars)
.map(envar => `${envar}=${envars[envar]}`)
.join(' ')
}`,
'node',
args.join(' ')
));
const envStr = Object.keys(envars)
.map(envar => `${envar}=${envars[envar]}`)
.join(' ');
const styled = chalk.dim(`$ ${envStr}`, 'node', args.join(' '));
console.log(styled);
const sensitiveEnv = [...];
const envStr = Object.keys(envars)
.filter(envar => !sensitiveEnv.includes(envar))
.map(envar => `${envar}=${envars[envar]}`)
.join(' ');
const styled = chalk.dim(`$ ${envStr}`, 'node', args.join(' '));
console.log(styled);Re: Pipe Operator (|>) For JavaScript
#108Is this: Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') |> `$ ${%}` |> chalk.dim(%, 'node', args.join(' ')) |> console.log(%); Really better than: console.log(chalk.dim( `$ ${Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') }`, 'node', args.join(' ') )); That's the real-world example they have (I reformatted the second one slightly, because it looks better to me). N…
You have nested backticks there. Is this really real code?
Yes, you can do that in lambdas:
> `${50}: ${[1,2,3].map(a => `${a+1}`)}`
'50: 2,3,4'
Re: Pipe Operator (|>) For JavaScript
#109Earlier quoted context omitted.
Indeed. The argument of “nested calls are hard to read” is strange, because this looks terrible
Anything looks better than nested calls once you have started to get used to the benefits of reading left-to-right. It's one of those pains you don't realize you have unless it suddenly goes away.
Nested calls can be a code smell, sure. But easily fixable:
one(two(three()));
let a=three();
let b=two(a);
one(b);
Re: Pipe Operator (|>) For JavaScript
#110This is similar to Elixir. It's such a natural way to program and so useful. I wish all languages had this.
Also shout out to bash pipes