// bad
class Listing extends React.Component {
render() {
return <div>{this.props.hello}</div>;
}
}
// bad (relying on function name inference is discouraged)
const Listing = ({ hello }) => (
<div>{hello}</div>
);
// good
function Listing({ hello }) {
return <div>{hello}</div>;
}
This is taken from the Airbnb react style guide. Can someone please explain why "relying on function name inference is discouraged"? Is it just a style concern?
I think this could also have something to do with the unexpected behaviour that you might run into from implicitly giving a lexical name to what you may expect to be an anonymous function.
Say for example someone understood the arrow function:
(x) => x+2;
To have the regular function equivalent:
function(x) {
return x+2;
}
It would be pretty easy to expect this code:
let foo = (x) => x+2;
To then be the equivalent of:
let foo = function(x) {
return x+2;
}
Where the function remains anonymous and would be incapable of referencing itself to do things like recursion.
So if then, in our blissful ignorance, we had something like this happening:
let foo = (x) => (x<2) ? foo(2) : "foo(1)? I should be a reference error";
console.log(foo(1));
It would successfully run because that function obviously wasn't anonymous:
let foo = function foo(x) {
return (x<2) ? foo(2) : "foo(1)? I should be a reference error";
}
This could potentially be exacerbated by the fact that in other situations where Babel implicitly adds a name to anonymous functions, (which I think is actually a bit of a side-effect of supporting implicit function names in the first place, though I could be wrong on that), they correctly handle any edge cases and throw reference errors where you would expect.
For example:
let foo = {
bar: function() {}
}
// Will surprisingly transpile to..
var foo = {
bar: function bar() {}
};
// But doing something like:
var foo = {
bar: function(x) {
return (x<2) ? bar(2) : 'Whats happening!?';
}
}
console.log(foo.bar(1));
// Will correctly cause a ReferenceError: bar is not defined
You can check 'view compiled' on this quick DEMO to see how Babel is actually transpiling that to maintain the behaviour of an anonymous function.
In short, being explicit with what you are doing is typically a good idea because you know exactly what to expect from your code. Discouraging the use of implicit function naming is likely a stylistic choice in support of this while also remaining concise and straightforward.
And probably hoisting. But hey, fun side trip.
Don’t forget to name the expression - anonymous functions can make it harder to locate the problem in an Error's call stack (Discussion)
MDN has a good run-down on how function name inference works, including two warnings:
There is non-standard <function>.name
inference behaviour in the following two scenarios:
The script interpreter will set a function's name property only if a function does not have an own property called name...
Be careful when using Function.name and source code transformations such as those carried out by JavaScript compressors (minifiers) or obfuscators
....
In the uncompressed version the program runs into the truthy-branch and logs 'foo' is an instance of 'Foo' whereas in the compressed version it behaves differently and runs into the else-branch. Therefore, if you rely on Function.name like in the example above, make sure your build pipeline doesn't change function names or don't assume a function to have a particular name.
The
name
property returns the name of a function, or (before ES6 implementations) an empty string for anonymous functions
function doSomething() {}
console.log(doSomething.name); // logs "doSomething"
Functions created with the syntax new Function(...) or just Function(...) have their name property set to an empty string. In the following examples anonymous functions are created, so name returns an empty string
var f = function() {};
var object = {
someMethod: function() {}
};
console.log(f.name == ''); // true
console.log(object.someMethod.name == ''); // also true
Browsers that implement ES6 functions can infer the name of an anonymous function from its syntactic position. For example:
var f = function() {};
console.log(f.name); // "f"
Personally I prefer (arrow) functions assigned to a variable for three basic reasons:
Firstly, I don't ever use function.name
Secondly, mixing lexical scope of named functions with assignment feels a little loose:
// This...
function Blah() {
//...
}
Blah.propTypes = {
thing: PropTypes.string
}
// ...is the same as...
Blah.propTypes = {
thing: PropTypes.string
}
function Blah() {
//...
}
// ALTERNATIVELY, here lexical-order is enforced
const Blah = () => {
//...
}
Blah.propTypes = {
thing: PropTypes.string
}
And thirdly, all things being equal, I prefer arrow functions:
this
, no arguments
etcI was listening to a Podcast and guest told of a situation were he had to deal with the limitations of using arrow functions with memory profiling, I have been in the exact same situation before.
Currently, memory snapshots will not include a variable name - so you might find yourself converting arrow functions to named functions just to hook up the memory profiler. My experience was quite straightforward, and I'm still happy with arrow functions.
Plus I've only used memory snapshots once, so I feel comfortable forgoing some "instrumention" for (subjective) clarity by default.
As any other style guide, Airbnb's is opinionated and isn't always well reasoned.
Function name
property isn't supposed to be used for anything but debugging in client-side application because function original name is lost during minification. As for debugging, it becomes less efficient if a function doesn't have a meaningful name in call stack, so it's beneficial to preserve it in some cases.
A function gets name
with both function definition like function Foo = () => {}
and function named expression like an arrow in const Foo = () => {}
. This it results in Foo
function having a given name, Foo.name === 'Foo'
.
Some transpilers follow the specification. Babel transpiles this code to ES5:
var Foo = function Foo() {};
And TypeScript breaks the specification:
var Foo = function () {};
This doesn't mean that named function expression is bad and should be discouraged. As long as a transpiler is spec-compliant or function name doesn't matter, this concern can be discarded.
The problem is applicable to transpiled applications. It depends on a transpiler in use and a necessity to keep function name
property. The problem doesn't exist in native ES6.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With