Do arrow functions have a higher priority than normal functions?

Question

Both of the following snippets print "arrow". I would like to know why. Do arrow functions have a sort of higher priority than the normal functions if they both have the same name?

function increment(){
    alert("normal")
}


var increment = () => {
    alert("arrow")
}

increment(); //prints arrow

var increment = () => {
    alert("arrow")
}


function increment(){
    alert("normal")
}


increment(); //prints arrow

Answer 1

This has nothing to do with arrow functions. Rather, regular functions (and var declarations) are hoisted; regardless of where you write them, they are moved to the top of their scope. Effectively, both code samples are completely identical, and they look like this:

var increment; // hoisted

function increment() { // hoisted
    alert("normal")
}

increment = () => { // the assignment itself is unaffected
    alert("arrow")
}

increment(); //prints arrow

The assignment portion of var increment = ... occur after the hoisted function and var declaration, in both cases. Regardless of where you actually wrote the function increment() { } declaration, it is hoisted above the line performing assignment to the increment variable.

This is why the following code still works, despite the function apparently being defined after it is used:

increment(); //prints normal

function increment(){
    console.log("normal")
}

If you want to compare like with like, you need to compare var increment = () => { ... } with var increment = function () { ... }, that is, two assignments. The results look like this:

var increment = () => { console.log('arrow'); }
var increment = function () { console.log('normal'); }

increment(); # normal

vs

var increment = function () { console.log('normal'); }
var increment = () => { console.log('arrow'); }

increment(); # arrow

In both cases there is a single hoisted var increment; declaration, and then the assignments occur in the order in which they're written, meaning the last assignment wins.

---

As an aside, this is one of the chief reasons to prefer let x = () => { } over "old" style function declarations. let is not hoisted, so the function exists from the point in time you would naturally expect it to, instead of jumping to the top of your scope.