Why using the whole babel plugins and flow definitions

[jsdario]

The question goes into 2 directions:

1. Why (if implemented on babel) are not we using the ECMAScript proposal syntaxlike?.this.directly.

2. Isn't it simpler to create a plain function wrapper? What are the advantages in comparison to the following:

function idx (expression: string) {
  try {
    return eval(expression)
  } catch (err) {
    return null // or process the error to check `undefined` against `null`
  }
}

// call afterwards binding scope

I understand the 2nd isn't ideal either (we are loosing flow power here, but I guess it could be still recovered improving the example function with some metaprogramming), but I would like to understand why of the syntax. Maybe just to have leaner code with flow annotations working, but then: what about the babel plugin?

[hzoo]

@jsdario for the first question, you can check the issue I made #1. I believe they just didn't know how far the proposal was and the status of it + Babel. Hopefully, we can have better communication in the future

[yungsters]

Thanks for your question, @jsdario.

At Facebook, we use Flow for type-checking (almost) all of our JavaScript. We generally do not add support for proposals until they are beyond the experimental phase (which I believe is roughly defined as "Stage 2"). Adding support for the existential operator proposal is slightly more involved because it involves changes to not only Flow, but the parser.

The proposal was also not even Stage 1 when we initially introduced idx into our codebase. And until it is more mature, we need something that allows us to use this pattern while maintaining support with Flow. The benefit of using a function (even one with somewhat arbitrary constraints) is that the tooling ecosystem (e.g. IDEs, linters, and Flow) already know how to work with them.

Some people have raised the point that even though idx uses valid JavaScript syntax, it still required a custom Flow declaration and Babel plugin. As I mentioned above, the custom Flow declaration was very low cost, and we already have a precedent for Babel plugins that inline code functions in the name of performance (e.g. invariant).

As soon as the existential operator is further along and supported by Flow, the plan is indeed to codemod all call sites of idx at Facebook to use it. When that happens, I'll likely also open source the jscodeshift to do so.

I hope this answers your question!