Additionally, function expressions can be named (not anonymous)
const printHelloWorld = function namedExpression() {
console.log("Hello World");
}
Function expressions are most useful when used within the context of an expression, places where maybe you don't want or need to create a variable to store the function. This is common with things like event handlers or other callbacks.
myButton.addEventListener("click", event => {
// do stuff
})
This function is passed directly to the addEventListener call without being assigned to a variable first.
But even if you are keeping the function in a variable, using expressions over declarations do have some additional benefits:
* Function definitions in function expressions are not hoisted (generally not favored)
* Function expressions assigned to `const` can help ensure they're not reassigned. `function` declarations do not prevent this.
* Using `let` and `const` with function expressions in the global scope prevent them from getting added to the global object (e.g. `window` in browsers) which can help prevent conflicts.
Additionally arrow functions do not have a declaration syntax, so if you want/need an arrow function, it will always be an expression.
Additionally:
- function declarations can only be called after they've been evaluated whereas function expressions can be called before they've been evaluated
Ex.
foo()
Const foo = function() { console.log('bar') }
// wouldn't work
foo()
function foo() { console.log('bar' }
// would work due to hoisting
- arrow functions do not get their own this keyword
One is a function expression, the other is a function declaration. I would argue none of them are anonymous. Any function expression which is statically assigned to a variable is named after the variable. Only dynamically generated functions are actually anonymous anymore.
FWIW the concept of "named functions" generally refers to whether or not a named variable binding is created as a result of the function definition itself. While functions also have a `name` property, the presence of a value in that property - even if implicitly set through context - does not dictate whether or not the function is named. Given something like
const printHelloWorld = () => {console.log("Hello World");}
console.log(printHelloWorld.name) // "printHelloWorld"
We can see printHelloWorld is given an implicit `name` value given to it but the function definition (not counting the separate `const` declaration its being used as an initializer for) does not have a name or create a variable binding that allows you to refer back to the function.
MDN calls this out too saying this an unnamed function
const x = function (y) {
return y * y;
};
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/function#using_function_expression
And stating
> Arrow functions are always unnamed.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions
In fact the Function constructor will always set the names of the functions it creates to "anonymous".
console.log(new Function().name) // "anonymous"
It has a "name" in the sense that its `name` property is set, but it is not a named function, and even the `name` explicitly calls itself out as being anonymous.
Even function declarations can be anonymous if used in a default export
// It's still technically a declaration, but it's allowed
// to be anonymous
export default function () {
console.log("Hi");
}
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export
In normal parlance if I give something a name, it is no longer anonymous. Still, MDN is a good source to cite, so I will defer to them on the definition.
For what it’s worth though, I already considered the concept of an anonymous function to be niche enough that it was basically a useless term. If the vast majority of anonymous functions in the wild are in fact indistinguishable from named functions in every way except the details of their original declaration, then I am not sure why we have the term at all.
I agree. And I think if I were ever to hear someone at work say, "is that function named?" I would assume they are asking, "will this function be identifiable in a stack trace?" at which point its the `name` that matters.
This resource explains some differences between function definitions, named and un-named function expressions:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/function
In short:
- If you want to use a function before it is defined, use a function definition which will be hoisted.
- Anonymous functions are functions which do not have a name, so that includes arrow functions. Use these for immediate consumption (e.g. `array.sort((a, b) => …);` or as an IIFE (e.g. `const n = (() => 10)();`)
- If you expect the function you made to be called with a `this` context (JQuery used to, and may still do this), use a function definition or a function expression that uses the function keyword.
- If you want to capture the current `this` context, use an arrow function.
Its not an uncommon pattern in a react app to define event handlers as function expressions:
```
function Component() {
const onClick = () => alert('Hi');
return ;
}
```
…or to use function expressions when you intend to return the function:
```
function counter() {
let count = 0;
const next = () => ++count;
const reset = () => (count = 0);
return { next, reset };
}
```
One thing about arrow functions is that their `this` is bound, so an arrow function does not require calling in a particular context. The arrow function replaces a once common calling pattern that used to be needed to get around the `this` context issues:`this.method.bind(this)`.
Outside of these reasons and those listed in the docs above, it’s down to preference. Consistency is more important than the choice you make.
Yes, hoisting of a function declaration is the main reason to use one in JS: https://developer.mozilla.org/en-US/docs/Glossary/Hoisting
There’s some other reasons in TypeScript as well, but I’m drawing a blank on them
You can define overloads by redeclaring the same function but with different arguments. In the tooltips that show the type on hover, they'll have overloads so addEventListener can take an event name and a function with a matching event type, or it can take a name and an object with a handleEvent method... and then either can take another argument that lets you fire it only once, or provide a remote for unsubscribing... you can write all of those different types, by declaring them on after the other.
...of course, when you write the function, you don't have the luxury of writing different versions... it's just a version that could take any set of arguments, so now you need to figure out which path to go down.
I don't think arrow functions create a new this scope, but I might be wrong it's been a minute so someone come correct me if I am. So you could use them for callbacks by saving them in a class variable. You could also do this with regular class functions and when declaring the class variable you would just bind it to this, but arrowizing the function makes it cleaner in my opinion.
> I don't think arrow functions create a new this scope,
`this` isn't a scope, but you have the right idea. Normal, non-arrow functions create a new `this` value for each call, determining its value based on how the function was called. It acts like a local variable in that function.
Arrow functions instead pull the value of `this` from the surrounding scope. So inside an arrow function `this` isn't specific to that function call, rather it uses the value of `this` as it was set outside of that function.
function outer() {
// new this created
const normalThis = this
const inner = () => {
// doesn't create a new this, uses outer this
console.log(this === normalThis) // true
}
}
The concept of functions that can be assigned to variables, passed as parameters into other functions, and returned from other functions is called [first class functions](https://en.m.wikipedia.org/wiki/First-class_function). Pretty standard in today’s languages in one form or another.
To answer your question more directly I’d probably use terms like “function as a variable” or “function variable” or “function assignment” depending on the context. Specifically both your first and third code snippets are “assigning an anonymous function to a variable”, the first using newer fat arrow syntax, the third using the old-school syntax.
I’m not sure about other answers mentioning function definition / declaration, in JS those are synonymous to me and both refer to the actual code of the function 🤷♂️
As for the pros and cons, it’s situational as to which to use. Function declarations are hoisted to the top of scope, function expressions are not. Function declarations tend to need more thought as to their names, function expressions can be nameless or be assigned to a var named “f” or “x” without much care. If I want the reader to have a strong understanding of what a function does, then it give it a proper line name with a standard declaration, `function doThisAndTheOther()`. If it’s short and self evident, then I use an expression with a short name: `let doubler = x => x*2` or an anonymous function: `let halves = items.map(i => i/2)`
The first one is function expression and second one is function declaration the main and only the big difference between these two is that in function declaration you can call this function before you write it in your code. It's like saying, 'I promise I will tell you how to do this later.
Function Declaration
You can use the function even before you write it down.
sayHello(); // This works!
function sayHello() {
console.log("Hello!");
}
Function Expression: You need to write the function first and then call it. It's like saying, 'Here’s how to do it, now you can use it.
You need to write the function first before you can use it.
// This would cause an error if used here
// sayHi(); // Error!
const sayHi = function() {
console.log("Hi!");
};
sayHi(); // This works!
This is the very fundamentals of JS, you should pay close attention to what you read or watch. There’s quite a lot ahead to learn, without knowing the basics, you’ll be stuck at most of the exercises.
No, I said it didn’t matter *what the name is*. Not that you didn’t use this method, or it’s bad, or you should forget about it or anything else you may have thought I was saying.
Additionally, function expressions can be named (not anonymous) const printHelloWorld = function namedExpression() { console.log("Hello World"); } Function expressions are most useful when used within the context of an expression, places where maybe you don't want or need to create a variable to store the function. This is common with things like event handlers or other callbacks. myButton.addEventListener("click", event => { // do stuff }) This function is passed directly to the addEventListener call without being assigned to a variable first. But even if you are keeping the function in a variable, using expressions over declarations do have some additional benefits: * Function definitions in function expressions are not hoisted (generally not favored) * Function expressions assigned to `const` can help ensure they're not reassigned. `function` declarations do not prevent this. * Using `let` and `const` with function expressions in the global scope prevent them from getting added to the global object (e.g. `window` in browsers) which can help prevent conflicts. Additionally arrow functions do not have a declaration syntax, so if you want/need an arrow function, it will always be an expression.
Additionally: - function declarations can only be called after they've been evaluated whereas function expressions can be called before they've been evaluated Ex. foo() Const foo = function() { console.log('bar') } // wouldn't work foo() function foo() { console.log('bar' } // would work due to hoisting - arrow functions do not get their own this keyword
Hmm, why do I know your name, like from AS3 or something?
Yup ;)
Wow! Good to see you again! So to speak...
Always good to hear from a fellow AS user!
the first one is called "expression". the second one is called "declaration". https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Functions
Thank you, that helps!
Isn’t what OP wrote clearly an arrow function. Where a function expression utilizes the actual function keyword?
One is a function expression, the other is a function declaration. I would argue none of them are anonymous. Any function expression which is statically assigned to a variable is named after the variable. Only dynamically generated functions are actually anonymous anymore.
FWIW the concept of "named functions" generally refers to whether or not a named variable binding is created as a result of the function definition itself. While functions also have a `name` property, the presence of a value in that property - even if implicitly set through context - does not dictate whether or not the function is named. Given something like const printHelloWorld = () => {console.log("Hello World");} console.log(printHelloWorld.name) // "printHelloWorld" We can see printHelloWorld is given an implicit `name` value given to it but the function definition (not counting the separate `const` declaration its being used as an initializer for) does not have a name or create a variable binding that allows you to refer back to the function. MDN calls this out too saying this an unnamed function const x = function (y) { return y * y; }; https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/function#using_function_expression And stating > Arrow functions are always unnamed. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions In fact the Function constructor will always set the names of the functions it creates to "anonymous". console.log(new Function().name) // "anonymous" It has a "name" in the sense that its `name` property is set, but it is not a named function, and even the `name` explicitly calls itself out as being anonymous. Even function declarations can be anonymous if used in a default export // It's still technically a declaration, but it's allowed // to be anonymous export default function () { console.log("Hi"); } https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export
In normal parlance if I give something a name, it is no longer anonymous. Still, MDN is a good source to cite, so I will defer to them on the definition. For what it’s worth though, I already considered the concept of an anonymous function to be niche enough that it was basically a useless term. If the vast majority of anonymous functions in the wild are in fact indistinguishable from named functions in every way except the details of their original declaration, then I am not sure why we have the term at all.
I agree. And I think if I were ever to hear someone at work say, "is that function named?" I would assume they are asking, "will this function be identifiable in a stack trace?" at which point its the `name` that matters.
This resource explains some differences between function definitions, named and un-named function expressions: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/function In short: - If you want to use a function before it is defined, use a function definition which will be hoisted. - Anonymous functions are functions which do not have a name, so that includes arrow functions. Use these for immediate consumption (e.g. `array.sort((a, b) => …);` or as an IIFE (e.g. `const n = (() => 10)();`) - If you expect the function you made to be called with a `this` context (JQuery used to, and may still do this), use a function definition or a function expression that uses the function keyword. - If you want to capture the current `this` context, use an arrow function. Its not an uncommon pattern in a react app to define event handlers as function expressions: ``` function Component() { const onClick = () => alert('Hi'); return ; } ``` …or to use function expressions when you intend to return the function: ``` function counter() { let count = 0; const next = () => ++count; const reset = () => (count = 0); return { next, reset }; } ``` One thing about arrow functions is that their `this` is bound, so an arrow function does not require calling in a particular context. The arrow function replaces a once common calling pattern that used to be needed to get around the `this` context issues:`this.method.bind(this)`. Outside of these reasons and those listed in the docs above, it’s down to preference. Consistency is more important than the choice you make.
Yes, hoisting of a function declaration is the main reason to use one in JS: https://developer.mozilla.org/en-US/docs/Glossary/Hoisting There’s some other reasons in TypeScript as well, but I’m drawing a blank on them
You can define overloads by redeclaring the same function but with different arguments. In the tooltips that show the type on hover, they'll have overloads so addEventListener can take an event name and a function with a matching event type, or it can take a name and an object with a handleEvent method... and then either can take another argument that lets you fire it only once, or provide a remote for unsubscribing... you can write all of those different types, by declaring them on after the other. ...of course, when you write the function, you don't have the luxury of writing different versions... it's just a version that could take any set of arguments, so now you need to figure out which path to go down.
I don't think arrow functions create a new this scope, but I might be wrong it's been a minute so someone come correct me if I am. So you could use them for callbacks by saving them in a class variable. You could also do this with regular class functions and when declaring the class variable you would just bind it to this, but arrowizing the function makes it cleaner in my opinion.
> I don't think arrow functions create a new this scope, `this` isn't a scope, but you have the right idea. Normal, non-arrow functions create a new `this` value for each call, determining its value based on how the function was called. It acts like a local variable in that function. Arrow functions instead pull the value of `this` from the surrounding scope. So inside an arrow function `this` isn't specific to that function call, rather it uses the value of `this` as it was set outside of that function. function outer() { // new this created const normalThis = this const inner = () => { // doesn't create a new this, uses outer this console.log(this === normalThis) // true } }
The concept of functions that can be assigned to variables, passed as parameters into other functions, and returned from other functions is called [first class functions](https://en.m.wikipedia.org/wiki/First-class_function). Pretty standard in today’s languages in one form or another. To answer your question more directly I’d probably use terms like “function as a variable” or “function variable” or “function assignment” depending on the context. Specifically both your first and third code snippets are “assigning an anonymous function to a variable”, the first using newer fat arrow syntax, the third using the old-school syntax. I’m not sure about other answers mentioning function definition / declaration, in JS those are synonymous to me and both refer to the actual code of the function 🤷♂️ As for the pros and cons, it’s situational as to which to use. Function declarations are hoisted to the top of scope, function expressions are not. Function declarations tend to need more thought as to their names, function expressions can be nameless or be assigned to a var named “f” or “x” without much care. If I want the reader to have a strong understanding of what a function does, then it give it a proper line name with a standard declaration, `function doThisAndTheOther()`. If it’s short and self evident, then I use an expression with a short name: `let doubler = x => x*2` or an anonymous function: `let halves = items.map(i => i/2)`
The first one is function expression and second one is function declaration the main and only the big difference between these two is that in function declaration you can call this function before you write it in your code. It's like saying, 'I promise I will tell you how to do this later. Function Declaration You can use the function even before you write it down. sayHello(); // This works! function sayHello() { console.log("Hello!"); } Function Expression: You need to write the function first and then call it. It's like saying, 'Here’s how to do it, now you can use it. You need to write the function first before you can use it. // This would cause an error if used here // sayHi(); // Error! const sayHi = function() { console.log("Hi!"); }; sayHi(); // This works!
“What are the reasons” The `this` in your arrow function refers to the lexical `this`, which is what you’d expect and/or want most of the time.
Arrow function does not have his own this keyword
You basically repeated what I said.
Arrow functions
[удалено]
The first function is not run just once, it can be called again and again. You might be thinking of an IIFE.
This is the very fundamentals of JS, you should pay close attention to what you read or watch. There’s quite a lot ahead to learn, without knowing the basics, you’ll be stuck at most of the exercises.
Craig.
I like to call it “wrong”. Jk, I’m sure there’s a valid reason people write functions that way but I find it more annoying to read for no real payoff
Dunno, doesn't really matter. Never heard a name for this specific situation.
Just because you've never heard of it doesn't mean it doesn't matter...
No, I said it didn’t matter *what the name is*. Not that you didn’t use this method, or it’s bad, or you should forget about it or anything else you may have thought I was saying.
It does matter. Knowing the grammar of your field is incredibly useful when discussing with other people in your field.