Don’t forget to name the expression - anonymous functions can make it harder to locate the problem in an Error's call stack (Discussion)
Original answer below
MDN has a good run-down on how function name inference works, including two warnings:
Observations
There is non-standard <function>.name
inference behaviour in the following two scenarios:
- when using script interpreters
The script interpreter will set a function's name property only if a function does not have an own property called name...
- when using js tooling
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.
What is function name inference?
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"
Opinion
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:
- communicate to reader that there is no
this
, no arguments
etc
- looks better (imho)
- performance (last time I looked, arrow functions were marginally faster)
EDIT: Memory snapshots
I 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.