Issue with "Arrow function expressions": Can be used to define methods

[alattalatta]

MDN URL: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions

What information was incorrect, unhelpful, or incomplete?

Does not have its own bindings to this or super, and should not be used as methods.

Indeed arrow functions are not suitable for methods on a plain JS objects as one of the doc's examples:

const a = {
  b: () => console.log(this), // Window or undefined
}

But when used within a class definition, I can use it to define methods (with a help of public class fields which modern browsers are supporting).

class A {
  b = () => { console.log(this) } // A
}
const a = new A()

Even though it isn't the classic method (can't be extended because no super), some prefer this syntax for classes that won't be extended, to avoid having to bind class methods manually when passing them as parameters. It's more relevant to JSX codebases where you have to pass methods as component props.

<Button onClick={a.b} />
{/* vs. */}
<Button onClick={a.b.bind(a)} />
{/* vs. */}
<Button onClick={() => a.b()} />

And the A.prototype.b is still considered a method: It belongs to an object (class instance) and it has its this set to the object.

Specific section or headline?

The intro.

What did you expect to see?

Other than "should not be used as methods".

Did you test this? If so, how?

Ran the code blocks I've written above.

MDN Content page report details

• Folder: en-us/web/javascript/reference/functions/arrow_functions
• MDN URL: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions
• GitHub URL: https://github.com/mdn/content/blob/main/files/en-us/web/javascript/reference/functions/arrow_functions/index.md
• Last commit: 0f1f6f7
• Document last modified: 2021-12-01T06:01:14.000Z

[Andrew-Cottrell]

And the A.prototype.b is still considered a method

The described approach defines an instance field rather than an instance method.

class A {
  b = () => { console.log(this) }
}

console.log(typeof A.prototype.b); // "undefined"
console.log(typeof new A().b);     // "function"

/* in the following an instance method would log {foo: "bar"} */
new A().b.call({foo: "bar"});   // A {b: ƒ}
new A().b.apply({foo: "bar"});  // A {b: ƒ}
new A().b.bind({foo: "bar"})(); // A {b: ƒ} 

The field's value might be a function that may be called as-a-method, but it doesn't match what people usually mean when talking about either static methods or instance methods. I suppose we could call it a pseudo-method, but it's probably for the best if MDN continues to keep things simple with the "should not be used as methods" recommendation.

[tabatkins]

Right, that is not at all a method; the this binding visible to it is the class itself (or something like that; I don't know the details), established by the binding environment for evaluating field definitions, and is completely unrelated to a method-like this that can be set at runtime by the call syntax or the meta-calling methods.

[ljharb]

"method" isn't a universally agreed-upon term.

I'd say a method is a function that behaves differently depending on its receiver (the this value), and thus an arrow function nor a bound function are eligible to ever be a method.

[ljharb]

Using arrow functions in public fields is a hacky, subpar way to fake having a regular method that's also auto-bound to instances. Here's how I'd do that now:

foo = this.foo.bind(this);
foo() {}

and here's how i'd do that when decorators are a thing:

@bound
foo() {}

[js-choi]

I'd say a method is a function that behaves differently depending on its receiver (the this value), and thus an arrow function nor a bound function are eligible to ever be a method.

For what it’s worth, the language specification itself uses the term “method” on functions that do not use the this binding, such as Object.values. Although in general it seems to prefer the clearer term “function properties”.

[ljharb]

The language specification uses a bunch of internal terms that don't precisely match colloquial usage - the editors are in fact currently discussing defining the term "method" and consistently using (or not using) the term. Either way, the spec's terminology should document reality, and shouldn't define it.

[alattalatta]

I agree that it's hacky, I'd prefer auto-bind which is basically what @ljharb wrote. Or I just avoid using classes at all.

And to come to think of it, I also agree with this:

I'd say a method is a function that behaves differently depending on its receiver (the this value), and thus an arrow function nor a bound function are eligible to ever be a method.

---

But then, if public class fields + arrow functions should be thought as an anti-pattern, I think this might deserve its own explanation, and/or clearer way of definition for the term, method. Searching "react class method binding" yields quite a lot of articles which list the pattern as a way to avoid manual binding. (Disclaimer: They don't usually explicitly claim the fields as "methods" at least... but they look like methods!)

From Method glossary:

A method is a function which is a property of an object. There are two kind of methods: Instance Methods which are built-in > tasks performed by an object instance, or Static Methods which are tasks that are called directly on an object constructor.

A public class field that happens to be a function is a function which is a property of an object. Is it not? This page may be used to state that bound functions and arrow functions can't be methods and reasons for it.

The spec also defines methods as nothing but a function property on an object ("function that is the value of a property") - but if they are discussing it, great!