Babel 7.5(babeljs.io)

https://babeljs.io/blog/2019/07/03/7.5.0

37 comments

I have a strong feeling that these pipeline operators are headed for the purgatory that decorators are languishing in, at least as far as official ECMA spec approval goes. But I hope to be proven wrong.

pier257 anni fa

Decorators are in stage 2. Have I missed something?

tracker17 anni fa

Decorators have been in stage 2 for a very, very, very long time at this point.

dotsarefun7 anni fa

cupofjoakim7 anni fa

The F# pipelines look interesting, but how should one think about this? It's a Stage 1 proposal, meaning it could actually not only be changed, but also be dropped from the TC39 consideration. Will future babel versions under the 7 tree keep supporting it?

Klathmon7 anni fa

I would really avoid using this in anything that you aren't okay with rewriting right now.

The pipeline proposal has multiple syntaxes right now that the community is trying to pick from and discuss.

The chances that the F#-style syntax will be chosen AND will make it to the language proper unchanged is VERY low in my opinion.

And if the community goes in a different direction, it's unlikely that the F# style will be maintained for all that long because it's still such an early stage proposal.

finchisko7 anni fa

Is there any chance, there will be codemods?

Klathmon7 anni fa

They could probably be made, but I still wouldn't rely on it.

Well working Codemods are difficult to make in many cases, and unless someone is paying for it, I don't think there will be many calls for one to translate between the syntaxes unless the proposal gains a lot of usage without settling on one.

[deleted]7 anni fa

snek7 anni fa

it's part of the stage 1 preset, and in the future it will either disappear from the stage 1 preset or move to the stage 2 preset.

bhurlow7 anni fa

I'm excited to use the pipeline operator but I was burned when I adopted a library (https://github.com/danprince/zaphod) which used the function bind operator only to find that lost major steam in TC39 process

uhryks7 anni fa

It really is a bummer... Pipelines look cool and straightforward but the bind operator is much more flexible and seems more adapted to the language's semantics.

spion7 anni fa

With partial application the situation is mitigated somewhat but bind offers other benefits by being a decent primitive to help explain how JS `this` works.

I wonder if there is a way to revive the proposal...

ianwalter7 anni fa

I’m excited for pipelines but I think the simple pipeline feels much more natural than the “smart” one and allows for destructuring props. Also, am I the only one that feels like the way await is handled in pipelines is backwards? Why not just add await before the function call like a normal function call?

kristiandupont7 anni fa

I guess it's because of potential ambiguity, it's discussed here: https://github.com/tc39/proposal-pipeline-operator/issues/14...

ianwalter7 anni fa

Thanks for linking. It doesn’t look like that discussion includes the “F#” arrow function style discussed in the babel release. I believe using this style would get rid of the ambiguity they were discussing since it could be handled in the same way as a async function outside of pipelines. I really like the consistency of that approach.

netdur7 anni fa

For your own sanity, for your future own self and whomever poor soul that maintain your code, do not use smart syntaxes, there's nothing smart about it, those are just unreadable shortcuts, please use longer and simpler to read syntaxes.

sametmax7 anni fa

I pity the guy who has to debug a code base full of:

    let newScore = fetch(url)
      |> await #
      |> #.json()
      |> await #
      |> #.ID;

frabert7 anni fa

I don't know, it seems pretty clear to me. It beats doing

  let newScore = (await (await fetch(url)).json()).ID

and no, a myriad of intermediate variables is not always a nice alternative. This syntax gives a clear view of what happens to the data without having to untangle deeps expressions. I like it.

dmitriid7 anni fa

The page shows a much more clear and readable alternative, F# pipelines:

  let newScore = fetch(url)
    |> await
    |> r => r.json()
    |> await
    |> obj => obj.ID;

Klathmon7 anni fa

Wouldn't this be a lot easier to understand and work with?

    let newScore = await fetch(url)
      .then(r => r.json())
      .then(obj => obj.ID)

I think another problem is that these are just examples that aren't necessarily representative of real-life use cases but more just try to show all the different ways of using the syntax in one small chunk.

_v7gu7 anni fa

That example is wrapped perfectly, so it seems a bit unneeded. A more complex example would be

    // helper for method calls in pipes
    const _ = new Proxy({}, {get(_i, c) { return (...args) => e => e[c](...args)}})

    document
      .querySelectorAll('.requestedIds')
      |> Array.from
      |> _.map(el => fetch(`//address/${el.value}`))
      |> Promise.all
      |> await
      |> _.map(re => re.json())
      |> Object.fromEntries
      |> processResponse

In this case, there is both methods and function calls, which complicates reading quite a bit. Converted to pipes, it's simply from top to bottom.

Klathmon7 anni fa

But reading it like this I greatly prefer the F# style since it reads a lot more straightforward and easy to understand what is happening.

That being said, can't you abuse the promise syntax to get something very similar right now? Since `.then` will wrap a non-promise return value in a promise, this would do the same as your example:

    Promise.resolve(document.querySelectorAll('.requestedIds'))
      .then(p => Array.from(p))
      .then(p => p.map(el => fetch(`//address/${el.value}`)))
      .then(p => Promise.all(p))
      .then(p => p.map(re => re.json())
      .then(p => Object.fromEntries(p))
      .then(p => processResponse(p))

But funnily enough, as I went to go write out that example, I realized that I have no idea what the hell is being passed into the `_.map` functions... Even me being lazy and using `p` as the variable name for each pipe, the version that writes it out is massively easier to understand in my opinion.

spion7 anni fa

I'd like to see the type signature of that `_` construct.

It seems to me like the bind operator would've made the extra complexity unnecessary.

_v7gu7 anni fa

_.map is basically syntatic sugar for p => p.map, only written with today's javascript capabilities. I just tried to implement the proposed #. Dynamic access to methods doesn't yield very nice type signatures.

dmitriid7 anni fa

Yes, in this particular case `then` works better. Pipes are a very generic pattern though, and are quite useful when you have a chain of operations (whether those operations are async or not).

darepublic7 anni fa

Hopefully there will be no issue adding a breakpoint to see the structure of obj, a common debugging necessity

dmitriid7 anni fa

Chrome dev tools let you put breakpoints inside promises, and debug promises in general. I guess they'll update the tools to let you set breakpoints inside pipes (at least I'm hoping so :) )

omegaworks7 anni fa

How does it read in your internal monologue? "await pound" doesn't convey a whole lot of semantic meaning to me.

I'm curious how others read it.

adrusi7 anni fa

Perl programmers read "$_" as "it".

So you could read the expression above as "fetch url, then await it, then get its json then await it, then get its ID"

Although I don't know why a syntax needs to be verbally legible, seems like an odd requirement to me.

omegaworks7 anni fa

There's a reason why Pearl is considered a write-only language.

Programming languages typically opt for either verbal legibility or having their symbols represent some understood structural / visual cue (like an arrow, for example). There's nothing about the character "#" that indicates the directionality of the operation visually, so I assumed there was some verbal mapping that I wasn't familiar with. ("Hash", "pound", "number", etc).

Typically programming languages are used to communicate procedures in ways that would allow human people with a similar set of cultural references to understand what is going on by reading it. Having verbal legibility allows people who know the language to explain very quickly to new people what is meant by a given symbol. Otherwise why #? It could be any symbol.

Communicating meaning for humans might not be the intent for javascript moving forward, given where WASM and transpilation is headed, so :shrug:

coldtea7 anni fa

You should pity people debugging very different constructs than this.

This is clear as day, and I haven't even read the proposal...

sametmax7 anni fa

I never said understanding, I said debugging. There are 4 implicit objects here (discounting proxies and wrappers), so unless you know them by heart, you have now idea what's in there. Then of course most debuggers will consider that one line, so to debug, you will hall have to split it in several ones to have the right to know what's going on. Plus, now that you have done it, what ? You put them back as they were ?

That's also hoping your code map files and your browser work well together, which is often not the case. Transpiled code is always a pain to debug at one point or another.

And that's just one line, a code back "full of those" will let you do the dance again and again. A very slow dance at that, cause babel is not the fastest horse in town.

Finally I'll pray your intern doesn't have to do it. But we all have teams full of good programmers right ?

conradfr7 anni fa

But that's wishful thinking, you could be wrong about what that code does.

coldtea7 anni fa

Not really. There's no magic in the code, it's a pretty well established construct, used in other languages for decades...

gforge7 anni fa

The pipe operator has was introduced to R a few years ago. It is one of those things I miss the most in js.

Debugging is an issue though. I commonly find myself splitting up the pipes into section in order to inspect the results and find exceptions. Breakpoints and stepping through code is probably the features I most often struggle with.

microcolonel7 anni fa

Cool, a bit more powerful, like ->> and -> in Clojure.