Pipes are cool but this falls pretty hard on the side of adding too much cruft to the language.
Pipe Operator (|>) For JavaScript
71–80 of 437 posts
Re: Pipe Operator (|>) For JavaScript
#72Is 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…
Method chaining is better, but you need the library/class/ code to support it. If you got a bunch of function it can’t help you. Pipe operator is useful for when you use other people’s code.
On the other hand, pipe is less useful when you don’t have partial application of function built-in. So yeah I think this is not worth it.
Re: Pipe Operator (|>) For JavaScript
#73> Deep nesting is hard to read […] Temporary variables are often tedious
I’m a little torn because pipes might be pretty nice, especially for prototype code and small projects. One thing this proposal doesn’t acknowledge is that for production code, deep nesting’s often impractical and often considered an anti-pattern in the first place, so making it easier isn’t a common need or problem to have in my experience. Usually I’m going the other way, having to make it more tedious. Using temporary variables and breaking apart nesting is, far more often than not, necessary in order to do proper error checking, and just to make code readable, commentable, and refactorable, etc. I feel like what we need is not a way to make deep nesting easier to read, it’s a way to make temporary variables less tedious, perhaps while also piping from one function to the next… that would be really helpful in a deeper way than just adding another chaining syntax. Is the syntax is stuck at “|>”? I guess it’s not possible to override bitwise-or (“|”), but “|>” feels maybe a little clunky?
Re: Pipe Operator (|>) For JavaScript
#74Is 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 do prefer the piped version mainly because it removes annoying nesting but that's not high on my prioritized list of discomforts. The issue of deeply nested function calls is a thing, but I just use some temp variables to avoid it when it really starts looking ugly.
Then again, this is my typical opinion to a lot of the proposals - I see what this is useful for but I haven't experienced enough pain to really argue for it. However, if it does make it into the spec then I will use it probably because it's there.
I also recognize my stance as one that not many people like in other contexts because it can be interpreted as me not looking to improve my situation. But on the flip side I think cluttering the language specification with a lot of superficial syntactic sugar is a mistake.
Re: Pipe Operator (|>) For JavaScript
#75Earlier 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…
There is another way that isn't _as_ kludgy, but still not as nice as the JavaScript proposal:
computation() |> then(&Map.put(my_map, key, &1))
Re: Pipe Operator (|>) For JavaScript
#76Can'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')Re: Pipe Operator (|>) For JavaScript
#77Can'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]
Came here to say this. I am learning Elixir on and off, and I think pipes are amazing.
Re: Pipe Operator (|>) For JavaScript
#78Is 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…
Both examples are not good. They are both very unreadable and an example of slapping things together without to look on readability.
Re: Pipe Operator (|>) For JavaScript
#79JavaScript 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
Yes I took a functional programming course with Racket. But in hindsight Javascript made me appreciate and understand functional programming way more.
Re: Pipe Operator (|>) For JavaScript
#80Earlier 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 has been supported by every browser that's not IE for like 6 years, and it's easily polyfillable if you need to support earlier.