DEV Community

Everything you should know about Javascript functions

Duomly on December 25, 2019

This article was originally published at JavaScript functions Function in programming is one of the most basic elements. It is a set of stateme...

Read full post

Ivan • Dec 25 '19

An arrow function is nothing more than the shorter syntax for declaring function expression.

This statement is incorrect. Though arrow function can be used for this purpose, its primary purpose is sharing context (this) with parent scope, which makes such functions ideal for passing as arguments to when calling function that can then execute it.

Prior to arrow functions introduction we would have to bind a function context when passing it as argument, as context would be lost otherwise.

class Greeter {
    greeting = 'hello';
    say1 = (name) => this.greeting + ' ' + name;

    say2(name) {
        return this.greeting + ' ' + name;
    }
}
function sayHi(name, greeterFn) {
   console.log(greeterFn(name));
}

var greeter = new Greeter();

sayHi('Bob', greeter.say1); // 'hello Bob'

// context is lost when passing function as argument of another function
sayHi('Bob', greeter.say2); // ' Bob'

// bind context
sayHi('Bob', greeter.say2.bind(greeter)); // 'hello Bob'

Daniel Santana • Dec 25 '19

The over simplification of what arrow functions are is really concerning for an article with such an audacious title.

There’s no mention of the fact that this within an arrow function will always try to find the nearest defined this at that scope.

No mention of the fact that bind is still there and you can still bind arrow functions for achieving some sort of currying approach.

Also there’s no mention that the keyword arguments will behave just like the keyword this, and not like a regular function.

And last but not least, there’s no mention of some of the nicest things about the arrow functions which is the possibility of not using the return keyword

I vouch for a more humble name for the article.

Duomly • Dec 25 '19 • Edited

Thanks for pointing that. You are right. I should mention this :)

Comment deleted

Daniel Bokor • Dec 25 '19 • Edited

Hi,

I agree with you, but I believe you may achieve the same result (I.e. use a closure for making sure the returned function gets invoked a single time) without the need of an IIFE, right?

Also, regarding the article, one more important thing about the arrow function is that it has a lexical ‘this’ bound to it’s parent scope.

Comment deleted

Daniel Bokor • Dec 25 '19

IIFE is just that - a function that is invoked right after its definition.

Closure is the way JavaScript (the engine and the scope manager) handles the scope of variables, i.e. it detects whether the execution context of the function that gets returned has a reference to a variable defined in its parent scope.
Even if the garbage collector should have taken care of the parent scope (i.e. remove the references from the memory), due to the fact that the returned function also has reference to the same variable, it "closes" upon that variable, thus we have a closure.

Given your first example (the one with placing an order), I wrote a small repl that exemplifies a non-IIFE function that takes advantage of closure.

repl.it/@danielbokor/closure-example

tl;dr any function may take advantage of closures within JS, not just the ones that are an IIFE

Comment deleted

Josh Lipinski • Dec 26 '19 • Edited

Fwiw the pattern of using iife's in js to call pseudo-methods without separately instantiating an object using "new" is so clean to me. I'm a huge fan of the revealing module pattern. Your pattern is interesting. One thing that drives me nuts is I've yet to find an es6 pattern that matches the revealing module pattern in terms of being self contained and simplistic. Module exports are wacky to me, having to create a new file for each "object" and exporting functions individually in order to namespace them. And static methods in a class dont have access to constructor properties. The revealing module pattern hit on all of this...And if I wanted to put a bunch of iife's in one file and make said functionality available globally - yet namespaced - I could. To me it's like we went backwards with these es6 imports...it's become more procedural. just a gripe.

Daniel Bokor • Dec 26 '19

I agree with you, using the IIFE has a single execution context thus there is a single closure.

My point was that closure may exist without the need of using an IIFE.

Also, you are right: we both know how to use closure ;)

Trakode • Dec 25 '19

This post gave me a quick reminder of what I already knew in javascript. You have to believe that see it from your point of view. Refreshes the brain

mihai • Dec 26 '19

you could continue this article with objects that have functions (methods) and how to use them.
also, didn;t you stop a function's run by using "return;" ? or im thinking of the functions that work on the DOM?