0

Calling a function before declaration works with the standard function declaration 

//calling the method prior to declaration...
greeter();

function greeter() {
    console.log("Hi there!!!");
}

but it does not work for arrow function or function binding way. Why??

//calling the method prior to declaration...
greeter();
const greeter = () => {
    console.log("Hi there!!!");
}
Striped
  • 2,352
  • 3
  • 21
  • 28
Kenny Omega
  • 338
  • 1
  • 10
  • Why should it? You see that there's a distinction to the point that you're aware of the term "functionn declaration", so one makes the function available and the other doesn't. Is there more to say? –  Mar 03 '18 at 15:34
  • The concept that allows the second to work is generally referred to as [hoisting](https://developer.mozilla.org/en-US/docs/Glossary/Hoisting). – Jared Farrish Mar 03 '18 at 15:35
  • @JaredFarrish: All function objects are created at runtime. Nothing is "parsed into existence". The declaration syntax just gets evaluated first in the runtime. –  Mar 03 '18 at 15:36
  • Or [Why when I call an arrow function declared globally in other's function definition I get a "is not defined"?](//stackoverflow.com/q/48612918) Or [When should I use Arrow functions in ECMAScript 6?](//stackoverflow.com/q/22939130) Or [Are variables declared with let or const not hoisted in ES6?](//stackoverflow.com/q/31219420) – Heretic Monkey Mar 03 '18 at 15:56

4 Answers4

2

Because this is a function expression and is similar to 

const greeter = function(){
    console.log("Hi there!!!");
}

And these functions are not hoisted. Only hoisted thing will be variable declaration const greeter.

Further reading about hoisting in JavaScript:

https://developer.mozilla.org/en-US/docs/Glossary/Hoisting

void
  • 33,471
  • 8
  • 45
  • 91
  • 2
    Care to explain the downvotes? – void Mar 03 '18 at 15:35
  • i don't get it too - you are absolutly right. Ppl here on SO vote down like maniacs if they do not understand anything or to achieve their badges. This is really sad....+1 from my side – messerbill Mar 03 '18 at 15:36
  • @messerbill thanks.. really appreciate that... but no one is maniac here :) Each one is a contributor and upto their capacity they help.. – void Mar 03 '18 at 15:38
  • i am not the OT ;) – messerbill Mar 03 '18 at 15:38
  • 1
    @messerbill aah! :D – void Mar 03 '18 at 15:38
  • 4
    Could be the fact that you answered an obvious duplicate, but I could be wrong... – Heretic Monkey Mar 03 '18 at 15:39
  • I don't think it's really a duplicate of that bug. This isn't about how to give the function a name; it's about the temporal dead zone between the start of the block and the variable's initialization. – Pointy Mar 03 '18 at 15:42
  • 1
    I can't vote, but the weird thing about this answer is that it just basically tells the OP what they already knows by using the word "hoisted". The OP has observed that the one is made available early and the other is not. "hoisted" is just another way of expressing that same fact. –  Mar 03 '18 at 15:43
  • @MikeMcCaughan but that doesnt deserve a downvote. Downvote essentially means wrong, erroneous, low quality posts.. – void Mar 03 '18 at 15:45
  • @Pointy: The temporal dead zone isn't a factor. Even if that didn't exist, the function wouldn't be available to call. –  Mar 03 '18 at 15:45
  • @doodlemeister okay so this answer I think focuses on two things.. 1. There is a concept called Hoisting which JS Engine performs on the code.. OP might click on the link and read more about it here. 2. How variable initializations are not hoisted but function declarations are. – void Mar 03 '18 at 15:47
  • @doodlemeister it's still a factor because of `const`. The variable is not initialized where it would be with `var`, but you're right at the end of the day neither will work. This kind of code only works if you use a function declaration and I have no idea why you would _want_ to write code like this – Damon Mar 03 '18 at 15:47
  • 2
    @void A downvote means "not useful", and not necessarily that it is wrong. – str Mar 03 '18 at 15:47
  • @doodlemeister true but it wouldn't be the same kind of error – Pointy Mar 03 '18 at 15:50
  • @Damon: It's not a factor WRT the question being asked. Yes, `const` semantics are different in that they create the TDZ, but it doesn't contribute to the inability to invoke the function. –  Mar 03 '18 at 15:50
  • @doodlemeister yea I agree with respect to the question - as I mentioned :) – Damon Mar 03 '18 at 15:54
0

greeter() works because it is a function declaration and it is hoisted, but like function expressions, arrow functions aren't hoisted.

Heretic Monkey
  • 10,498
  • 6
  • 45
  • 102
brk
  • 43,022
  • 4
  • 37
  • 61
0

What is hoisting?

Conceptually, for example, a strict definition of hoisting suggests that variable and function declarations are physically moved to the top of your code, but this is not in fact what happens. Instead, the variable and function declarations are put into memory during the compile phase, but stays exactly where you typed it in your coding.

Arrow functions are not hoisted.

Actually it's a bit more complex than that, this stackoverflow answer is a good reference: Are variables declared with let or const not hoisted in ES6?

Andre Goncalves
  • 3,810
  • 2
  • 18
  • 15
0

Assignment initializations aren't hoisted. So you can't hoist an arrow function as it mostly behave as it. See it below:

It works:

greeter();

function greeter(){
    console.log("Hi there!!!");
}

It doesn't works:

greeter();

var greeter = myFunc; // this assignment will not be hoisting

function myFunc(){
    console.log("Hi there!!!");
}

It doesn't works neither:

greeter();

const greeter = () => {
    console.log("Hi there!!!");
}
guijob
  • 3,851
  • 1
  • 17
  • 31
  • wouldn't the correct formulation be `Initializations will not be hoisted`? - because this behaviour does not only affect function initializations but also variable initializations – messerbill Mar 03 '18 at 15:56
  • 1
    yeah, i've just edited it – guijob Mar 03 '18 at 16:05