> three(two(one(value)))
const oned = one(value);
const twoed = two(oned);
const threed = three(twoed);
This proposition goes out of its way to find problems with code that is written in a confusing and uncommon way in the first place.
Pipe Operator (|>) For JavaScript
31–40 of 437 posts
Re: Pipe Operator (|>) For JavaScript
#32previously: https://news.ycombinator.com/item?id=28916775
Re: Pipe Operator (|>) For JavaScript
#33Earlier 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…
Clojure has thread first ->, thread last -> and even thread as as->, to define where the pipe will be applied. I find it very cool!
Re: Pipe Operator (|>) For JavaScript
#34Can'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]Re: Pipe Operator (|>) For JavaScript
#35The pipe operator is awesome because you can use it to “extend” objects without messing with their prototypes.
Missing String.titleCase ? Write your own!
“hello world” |> titleCaseRe: Pipe Operator (|>) For JavaScript
#36They should have stuck with the F# proposal. The hack proposal just takes one more giant step toward turning JS into Perl. Hack proposal value |> foo(%) for unary function calls, value |> foo(1, %) for n-ary function calls, value |> %.foo() for method calls, value |> % + 1 for arithmetic, value |> [%, 0] for array literals, value |> {foo: %} for object literals, value |> `${%}` for template literals, value |> new Foo…
I originally thought you were referring to this as a "hack proposal" as a way of denigrating its value, but in fact it is the "Hack proposal" where "Hack" is Facebook's fork of PHP.
Re: Pipe Operator (|>) For JavaScript
#37Earlier quoted context omitted.
Browsers have established they can roll out changes behind feature flags, and the community adapts and adopts them. This is a solved problem. ES6 transition, await/async, string templates, etc. were major JS changes that required browsers and runtimes to change. They did. It was fine. They can do it again!
Promise added a very valuable new capability, but this would just mean what you write doesn't work on any non updated browser for a very minor syntax improvement. If there are too many nested calls, assign some of the function results to variables first.
Async/await is pure syntactic sugar. Look at python 3.0 era coroutines that were iterator/generator based as an example of async coding without special keywords. JS did not need those keywords to enable coroutines and async coding. People were already making their own promises, coroutines, etc. long before the new keywords were added.
Re: Pipe Operator (|>) For JavaScript
#38Is 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…
The Hack proposal is horrible imo because it doesn’t look like JS anymore. The F# proposal is 99% of the benefit whilst being actually approachable.
Re: Pipe Operator (|>) For JavaScript
#39Earlier quoted context omitted.
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…
From what I understand the constraint is intentional to guide you in the direction of writing simple pipe chains.
That's probably a wise choice. Pipes are great for simple situations, mostly for code clarity. But it can be abused easily, like a hammer seeking nails.
It's similar to await/async, you eventually start designing code that better suits that interface rather than pigeonholing it with complex syntax.
Re: Pipe Operator (|>) For JavaScript
#40JavaScript isn't that kind of programming language. I don't know why people are constantly trying to make it something else.
Javascript is, without exaggeration (and with much chagrin), the language that has done more to popularize functional programming than any other programming language in history. It's only natural that they'd continue pushing on that front. :P