Add option to arrow-body-style to disallow braces for single-statement functions

What rule do you want to change?

arrow-body-style

Does this change cause the rule to produce more or fewer warnings?

More

How will the change be implemented? (New option, new default behavior, etc.)?

I’d be happy if it was a new option or if as-needed changed its behavior.

Please provide some example code that this change will affect:

let foo = () => { bar(); };

I’d like to propose What does the rule currently do for this code?

Currently, that code is considered correct for as-needed.

What will the rule do after it’s changed?

If the proposed enhancement is a change to as-needed, that code would become incorrect.

If the proposed enhancement is a new option, the new option would function exactly like as-needed except that code would become incorrect.

---

While it is technically different from let foo = () => bar(); because the return value is undefined for the with-braces version but the brace-less version returns the return value of bar(), in day-to-day code it often doesn’t make a difference. It is often stylistically cleaner not to have the braces, especially when using an auto-formatter like Prettier.js that multi-lines every brace-including arrow function.

Examples of code that don’t care whether the braces are there (return undefined implicit) or not (return the statement’s value):

imgTag.onload = () => myApp.showSuccess();

Ember.run(() => this.set('foo', 'bar'));

QUnit.assert.throws(() => myApp.shouldThrow());

[not-an-aardvark]

Nope, the suggestion to use an extra return is only in cases where the implicit undefined return value of a single-statement arrow function with a block matters.

Yes, that’s what I meant – sorry, my wording was a bit unclear. Thanks for clarifying.

In the same vein, returning undefined by including a block because braces were typed (“because other functions have braces so why not this one”) seems like it could cause confusion due to a lack of explicitness; when reading and refactoring, it might be difficult to tell which undefined return values are actually used, and which undefined return values are only present because the developer “accidentally” used braces.

I’m not sure I follow. Could you elaborate on what you mean by “accidentally” using braces?

---

Here’s an example to demonstrate what I mean about readability:

// Sample A
doSomethingWithACallback(() => foo());

// Sample B
doSomethingWithACallback(() => {
    foo();
});

// Sample C
doSomethingWithACallback(() => {
    foo();
    bar();
});

// Sample D
doSomethingWithACallback(() => {
    bar();
    return foo();
});

Suppose my code looks like Sample A, and I want to update the callback so that bar() gets called in addition to foo(). From just looking at the code, it’s not clear whether the return value of foo() is used in doSomethingWithACallback. If the return value is unused, then the correct update would look like Sample C. If the return value is used, then the correct update would look like Sample D (to ensure that the same value is returned as before). In order to figure out the correct refactoring, I might have to look at the implementation of doSomethingWithACallback and/or foo.

On the other hand, if my code initially looks like Sample B, then it’s clear that the return value of foo is not being used, because it never leaves the callback. So I can immediately tell that Sample C would be the correct refactoring, without needing to look at the implementation of doSomethingWithACallback or foo.

In other words, in the case where a return value is unused, Sample B is more “explicit” than Sample A in that it provides more clarity about how the system behaves. The intent is clear based on the presence of the block, despite the fact that the return keyword doesn’t appear anywhere in the text.

[Kerrick]

@Kerrick the different is that == vs === is likely a bug; the likely bug is omitting the braces, unintentionally exposing a return value, which unintentionally becomes part of the contract of your function.

You raise a really good point here. I had considered it to be more about accidentally not returning a value, but you’re probably right that the more likely accident is to return a value you didn’t intend.