Flow: Support function bind syntax (stage 0)

[samwgoldman]

https://github.com/zenparsing/es-function-bind

People ask for this regularly, but the proposal is still stage 0 and somewhat controversial. We have no plans to do this work until either a) it advances to stage 3 of b) we see a groundswell of support for this issue (reactions welcome).

[bordoley]

Interesting to note that the RxJs team is actively encouraging use of the bind operator as a best practice with the RxJS 5 beta.

[samwgoldman]

That's bold, since the proposal is still stage 0. That doesn't really change my feelings about Flow support.

[mmazzarolo]

It's true that supporting a stage 0 feature might be a risky move, but in my opinion flow should support at least one kind of not-too-much-verbose binding syntax (spoiler alert: this post is related to #1517).

Edit: nevermind, I updated my post in that thread, it seems that class methods need an ending semicolon for being used with flow.

[Anahkiasen]

I don't mind Flow not supporting this but could it at least be ignored the same way decorators can be? Currently any file with a :: just crashes, and that can quickly be very problematic. That's the current reason preventing me from using Flowtype personally.

[willclarktech]

If not included, at least a way to suppress the parsing error would be great. See #662

[vkurchatkin]

Decorators can be ignored because they are not statements or expressions, and in a lot of cases they are only used to attach some metadata, so flow can simply behave if they are not there. This is not true for bind operator, stripping it off will simply make your code incorrect in most cases.

[appsforartists]

eslint let's you specify a parser (e.g. Babel) that understands syntaxes it doesn't. That way, you can use experimental/bespoke syntactic sugars without breaking the tooling. I wonder what that would look like in Flow. Maybe Flow could use Babel + source maps to understand the translated code but still put the errors in the correct place in your original file. Not sure what the impact would be on speed though.

[jsheetzati]

:: is pretty common in React examples. Surprised flow doesn't support it.

[iansinnott]

could it at least be ignored the same way decorators can be?

Completely agreed with @Anahkiasen. The fact that ignore comments like// $FlowFixMe cannot be used to suppress these errors means that just one use of :: in a file and the whole file must be ignored.

Maybe instead of ignoring this syntax globally Flow could simply allow suppression.

[salanki]

Currently any file with a :: just crashes, and that can quickly be very problematic. That's the current reason preventing me from using Flowtype personally.

+1

[DarrylD]

any progress on this?

[gajus]

There are a lot bigger priorities (like solving all the existing bugs) than catering for bleeding edge (stage 0) proposals.

This proposal does not even have a champion (https://github.com/tc39/proposal-bind-operator/issues/24).

@jsheetzati
:: is pretty common in React examples. Surprised flow doesn't support it.

Source?

If not included, at least a way to suppress the parsing error would be great. See #662

Enabling suppression of parsing error would in effect require adding parsing to Flow core. Which comes back to the original problem – this being stage 0 proposal. Using this logic, we should add all stage 0/1/2 proposal syntax support to Flow core.

Completely agreed with @Anahkiasen. The fact that ignore comments like// $FlowFixMe cannot be used to suppress these errors means that just one use of :: in a file and the whole file must be ignored.

Don't use Flow for this file. You can isolate use of :: to small helper-containing files if thats the intention.

[goooseman]

Instead of writing

class Test extends React.Component {
  _foo () {console.log(this)}
  render () {
    return <Bar foo={::this._foo} />
  }
}

You can use

class Test extends React.Component {
  _foo = () => {console.log(this)}

  render () {
    return <Bar foo={this._foo} />
  }
}

This works fine: the function gets this context and Flow works with it fine.

[pronebird]

We use :: a lot. Is there any way to silence this error at least?

[DTupalov]

We use :: a lot, too. Is there any way to silence this error at least?

[smikhalevski]

@pronebird @DiMoNTD I've created a tiny example of how Flow can be used with function bind operator https://github.com/smikhalevski/flow-function-bind.

In my projects I heavily use :: and lack of its support in Flow is frustrating. So +1 for adding this feature to the core!

[ticky]

I’d like to put down a vote for including this, too. We’re making use of the syntax in buildkite/frontend and right now this limits our ability to adopt Flow in any serious manner, as it simply chokes on some of our code.

I have ended up down a weird rabbit hole of adapting @smikhalevski’s approach to work with SublimeLinter as well as in CI using an intermediary script which pipes Babel output into Flow, and unfortunately using Babel to transform _just_ this bit of code changes our code’s layout sufficiently that we end up with output in weird places!