Add rule to forbid "chained arrows"

[getify]

Because some of us feel that chained arrow returns (such as are common in curried function definitions) is much harder to read, given that you basically have to read them right-to-left to figure out where the function boundaries are, add rule that forbids chained arrow returns:

var f => x + 1;   // not chained, OK

var g => x => y => x + y;   // Error

Also, we need a flag to optionally allow/ignore these:

var g = x => (y => x + y);
var g = x => { return y => x + y; }

[the-simian]

I feel like an element of this proposal with utility would be to enforce a certain depth (rather than wholistically allow or disallow entirely). You could, of course, set a depth of 0 (allow nothing).

Reasoning: This patterns nice to add args into scope for things like event handlers/ map, where a developer may need additional args in the closure, and the 'last' function has predetermined args. Here an enforced chaining depth is useful. It also allows devs to use curried functions as a practice but prevents 'over currying' where one might want to investigate more practical abstractions.

With depth, regardless of a developers comfort zone, they can tweak this rule to their taste.

[getify]

From: https://twitter.com/dev01ution/status/1105209319174361090

Perhaps another option could be to allow a chained arrow return if it's surrounded by parentheses?

fn = x => y => x + y;   // error
fn = x => ( y => x + y );  // OK

[getify]

BTW, for consistency, I think this rule will actually be called "return", and will merge in the existing "object-return" behavior, so that one rule controls the various options on "return" values, and one controls the various options on "params".

[getify]

@the-simian Just curious, can you show me an example where you like using the chained arrow?

Does it look something like?

btn.addEventListener(
  "click",
  (data => evt => doSomething(data,evt))( mydata )
);

I'm not really clear on the use case.

[gearskullguy]

I'm curious why this was closed, even though I'm uncomfortable with the idea of JavaScript throwing errors or failing a script because it's not as "readable" as another JavaScript developer thinks it should be.

[getify]

It was closed because the feature being discussed -- a configurable rule about chained arrow function returns -- in this thread was added.

By definition, what linters do is apply opinions to your code. You may agree with the opinions or disagree with them, but that's what linters are for. The best thing is when linter tools are configurable, so you (and your team) can make the decision about which opinions you agree with and find helpful, and which ones you don't.

So, you can use this linter plugin or not use it. And if you use it, you can configure whichever included rules you like or not, so you can benefit from parts of it even you disagree with others.

Or don't. Makes no difference to me. That's the beauty of configurable rules!

[andys8]

I agree and disagree at the same time. It's fine to have different opinions. It's difficult to use this as an argument to add unnecessary parentheses or forbid a powerful feature like currying.

[getify]

@andys8 ok that's fine to feel that way. don't use the rule. There are other rules in the plugin to consider.

BTW I use currying all the time, I just don't do it syntactically. It's mis-stated to say this prevents currying.