About The Author

Jaime González García (@Vintharas) Software Developer and UX guy, speaker, author & nerd

Jaime is a full stack web developer and UX designer who thinks it’s weird to write about himself in the third person. During the past few years of his career he has been slowly but surely specializing in front-end development and user experience, and somewhere and some time along the way he fell in love with JavaScript. He still enjoys developing in the full stack though, bringing ideas to life, building things from nothingness, beautiful things that are a pleasure and a delight to use.

Jaime works as a Technical Solutions Consultant at Google helping publishers be great. He also builds his own products in his spare time and blogs at barbarianmeetscoding.com (long story that one). He loves spending time with his beloved Malin, drawing, writing, reading fantasy and sci-fi, and lifting heavy weights

About the Technical Reviewers

Nathan Gloyn (@NathanGloyn) Passionate developer, architect and speaker

Independent software consultant and agile coach, Nathan is passionate about development and a firm believer in agile principles. In his day job he is contractor helping clients to build and deliver working software.

Nathan has successfully bootstrapped agile teams in various companies and has given presentations on technology and agile at a number of events.

Andreas Bäcklund (@andbackl) Consultant, passionate programmer

Andreas is a consultant, passionate programmer, double master and a lifelong learner.

Andreas enjoys all sorts of tech and has been developing software that runs on everything from ship engines to the cloud. He enjoys working in the full stack because it’s rewarding, exciting and challenging, all at the same time.

Prelude

It was during the second age 
that the great founder of our order Branden Iech,

first stumbled upon the arcane REPL,
and learnt how to bend the fabric of existence to his very will,  

then was that he discovered 
there was a mechanism to alter the threads
being weaven into the Pattern,  

then that we started experiencing the magic of JavaScript  

        - Irec Oliett,  
        The Origins of JavaScript-Mancy  
        Guardian of Chronicles, 7th Age  

Imagine… imagine you lived in a world were you could use JavaScript to change the universe around you, to tamper with the threads that compose reality and do anything that you can imagine. Well, welcome to the world of JavaScript-mancy, where wizards, also known as JavaScriptmancers, control the arcane winds of magic wielding JavaScript to and fro and command the very fabric of reality.

We, programmers, sadly do not live in such a world. But we do have a measure of magic ¹ in us, we have the skills and power to create things out of nothingness. And even if we cannot throw fireballs or levitate (yet), we can definitely change/improve/enhance reality and the universe around us with our little creations. Ain’t that freaking awesome?

Well, I hope this book inspires you to continue creating, and using this beautiful skill we share, this time, with JavaScript.

A Story About Why I Wrote This Book

I was sitting at the back of the room, with my back straight and fidgetting with my fingers on the table. I was both excited and nervous. It was the first time I had ventured myself to attend to one of the unfrequent meetings of my local .NET user group. Excited because it was beyond awesome to be in the presence of so many like-minded individuals, people who loved to code like me, people who were so passionate about software development that were willing to sacrifice their free time to meet and talk about programming. Nervous because, of course, I did not want to look nor sound stupid in such a distinguished group of people.

The meetup started discussing TypeScript the new superset of JavaScript that promised Nirvana for C# developers in this new world of super interactive web applications. TypeScript here, TypeScript there because writing JavaScript sucked… JavaScript was the worst… everybody in the room started sharing their old war stories about writing JavaScript, how bad it was in comparison to C#, and so on…

“Errr… the TypeScript compiler writes beautiful JavaScript” I adventured to say… the room fell silent. People looking astonishingly at each other, uncomprehending, unbelieving… Someone had dared use beautiful and JavaScript in the same sentence.

This was not the first, nor will be the last time I have encountered such a reaction and feelings towards JavaScript as predominant in the .NET community. JavaScript is not worthy of our consideration. JavaScript is a toy language. JavaScript is unreliable and behaves in weird and unexpected ways. JavaScript developers don’t know how to program. JavaScript tooling is horrible…

And every single time I sat muted, thinking to myself, reflecting, racking my brains pondering… How to show and explain that JavaScript is actually awesome? How to share that it is a beautiful language? A rich language that is super fun to write? That’s how this book came about.

And let me tell you one little secret. Just some few years ago I felt exactly the same way about JavaScript. And then, all of the sudden, I started using it, with the mind of a beginner, without prejudices, without disdain. It was hard at first, being so fluent in C# I couldn’t wrap my head around how to achieve the same degree of fluency and expressiveness in JavaScript. Nonetheless I continued forward, and all of the sudden I came to love it.

The problem with JavaScript is that it looks too much like C#, enough to make you confident that you know JavaScript because you know C#. And just when you are all comfortable, trusting and unsuspecting JavaScript smacks you right in the face with a battle hammer, because, in many respects, JavaScript is not at all like C#. It just looks like it on the surface.

JavaScript is indeed a beautiful language, a little rough on the edges, but a beautiful language nonetheless. Trust me. You’re in for a treat.

Why Should You Care About JavaScript?

You may be wondering why you need to know JavaScript if you already grok C#.

Well, first and foremost, JavaScript is super fun to write. Its lack of ceremony and super fast feedback cycles make it a fun language to program in and ideal for quick prototyping, quick testing of things, tinkering, building stuff and getting results fast. If you haven’t been feeling it for programming lately, JavaScript will help you rediscover your passion and love for programming.

JavaScript is the language of the web, if you are doing any sort of web development, you need to understand how to write great JavaScript code and how JavaScript itself works. Even if you are writing a transpiled language like TypeScript or CoffeeScript, they both become JavaScript in the browser and thus knowing JavaScript will make you way more effective.

But JavaScript is not limited to the web, during the past few years JavaScript has taken the world by storm, you can write JavaScript to make websites, in the backend, to build mobile applications, games and even to control robots and IoT devices, which makes it a true cross-platform language.

JavaScript is a very approachable language, a forgiving one, easy to learn but hard to master. It is minimalistic in its contructs, beautiful, expressive and supports many programming paradigms. If you reflect about JavaScript features you’ll see how it is built with simplicity in mind. Ideas such as type coercion (are “44” and 44 so different after all?) or being able to declare strings with either single or double quotes are great expressions of that principle.

JavaScript’s openness and easy extensibility are the perfect foundations to make it a fast-evolving language and ecosystem. As the one language for the web, the language that browsers can understand, it has become the perfect medium for cross-pollination across all software development communities, where .NET developers ideas can meet and intermingle with others from the Ruby and Python communities. This makes knowledge, patterns and ideas spread accross boundaries like never before.

Since no one single entity really controls JavaScript², the community has a great influence in how the language evolves. With a thriving open source community, and openness and extensibility built within the language, it is the community and the browsers the ones that develop the language and the platform, and the standard bodies the ones that follow and stabilize the trends. When people find JavaScript lacking in some regard, they soon rush to fill in the gap with powerful libraries, tooling and techniques.

But don’t just take my word for it. This is what the book is for, to show you.

What is the Goal of This Book?

This book is the first installment of the JavaScript-mancy series and its goal is to provide a great and smooth introduction to JavaScript for C# developers. If you are a C# developer that has had no or little experience with JavaScript before then this book will help you get started. If you have had quite a bit of experience with JavaScript but it is still frustrating and you don’t understand why things behave the way they do, then this book will boost your JavaScript Fu until you start enjoying the language.

What is the Goal of The JavaScript-mancy Series?

The goal of the JavaScript-mancy series is to make you fluent in JavaScript, able to express your ideas instantly and build awesome things with it. You’ll not only learn the language itself but how to write idiomatic JavaScript. You’ll learn both the most common patterns and idioms used in JavaScript today, and also all about the latest version of JavaScript: ECMAScript 6 (also known ECMAScript 2015) and even about the upcoming version ECMAScript 7.

But we will not stop there because what is a language by itself if you cannot build anything with it. I want to teach you everything you need to be successful and have fun writing JavaScript after you read this series. And that’s why we will take one step further and take a glance at the JavaScript ecosystem, the JavaScript community, the rapid prototyping tools, the great tooling involved in building modern JavaScript applications, JavaScript testing and building an app in a modern JavaScript framework: Angular 2.

Why JavaScript-mancy?

Writing code is one of my favorite past times and so is reading fantasy books. For this project I wanted to mix these two passions of mine and try to make something awesome out of it.

In fantasy we usually have the idea of magic, usually very powerful, very obscure and only at the reach of a few dedicated individuals. There’s also different schools or types of magic: pyromancy deals with fire magic, allomancy relates to magic triggered by metals, necromancy is all about death magic, raising armies of skeletons and zombies, immortality, etc.

I thought that drawing a parallel between magic and what we programmers do daily would be perfect. Because it is obscure to the untrained mind and requires a lot of work and study to get into, and because we have the power to create things out of nothing.

And therefore, JavaScript-mancy, the arcane art of writing awesome JavaScript.

Is This Book For You?

I have written this book for you C# developer:

• you that hear about the awesome stuff that is happening in the realm of JavaScript and are curious about it. You who would like to be a part of it, a part of this fast evolving, open and thriving community.
• you that have written JavaScript before, perhaps even do it daily and have been frustrated by it, by not been able to express your ideas in JavaScript, by not being able to get a program do what you wanted it to do, or struggling to do so. After reading this book you’ll be able to write JavaScript as naturally as you write C#.
• you that think JavaScript a toy language, a language not capable of doing real software development. You’ll come to see an expressive and powerful multiparadigm language suitable for a multitude of scenarios and platforms.

This book is specifically for C# developers because it uses a lot of analogies from the .NET world, C# and static typed languages to teach JavaScript. As a C# developer myself, I understand where the pain points lie and where we struggle the most when trying to learn JavaScript and will use analogies as a bridge between languages. Once you get a basic understanding and fluency in JavaScript I’ll expand into JavaScript specific patterns and constructs that are less common in C# and that will blow your mind.

How is The Book Organized?

This is the introductory book to Part I. Mastering the Art of JavaScript-mancy which aims to teach you how to write JavaScript with fluency.

We will start by taking a quick walkthrough through all that JavaScript has to offer from types, functions and objects, to data structures, exception handling and regular expressions.

Then we will do a deep dive into JavaScript functions which are more common-place and live more independent lives in JavaScript than in C#. You’ll learn different patterns to do defaults, multiple arguments, function overloading in both ES5 and ES6.

We will continue taking a look at objects in JavaScript and at the many improvements that ES6 brings to object literals.

After you’ve learned more about functions and objects, two core constructs of JavaScript, we will discuss the big gotchas where we C# developers usually get stuck and stumble focusing particularly in the behavior of the this keyword.

We will finish this introduction to JavaScript with a look at some great ES6 features that will improve the readability of your code and at JavaScript data structures: the super useful and polifacetic array, the map and the set.

How Are The JavaScript-mancy Series Organized? What is There in the Rest of the Books?

The rest of the books are organized in 3 parts focused in the language, the ecosystem and building your first app in JavaScript.

After this introductory book Part I. Mastering the Art of JavaScript-mancy continues by examining object oriented programming in JavaScript, studying prototypical inheritance, how to mimic C# (classic) inheritance in JavaScript. We will also look beyond class OOP into mixins, multiple inheritance and stamps where JavaScript takes you into interesting OOP paradigms that we rarely see in the more conventional C#.

We will then dive into functional programming in JavaScript and take a journey through LINQ, applicative programming, immutability, generators, combinators and function composition.

Organizing your JavaScript applications will be the next topic with the module pattern, commonJS, AMD (Asynchronous module definition) and ES6 modules.

Finally we will take a look at Asynchronous programming in JavaScript with callbacks, promises and reactive programming.

Since adoption of ES6 will take some time to take hold, and you’ll probably see a lot of ES5 code for the years to come, we will start every section of the book showing the most common solutions and patterns of writing JavaScript that we use nowadays with ES5. This will be the perfect starting point to understand and showcase the new ES6 features, the problems they try to solve and how they can greatly improve your JavaScript.

In Part II. Welcome to The Realm Of JavaScript we’ll take a look at the JavaScript ecosystem, following a brief history of the language that will shed some light on why JavaScript is the way it is today, continuing with the node.js revolution and JavaScript as a true cross-platform, cross-domain language.

Part II will continue with how to setup your JavaScript development environment to maximize your productivity and minimize your frustration. We will cover modern JavaScript and front-end workflows, JavaScript unit testing, browser dev tools and even take a look a various text editors and IDEs.

We will wrap Part II with a look at the role of transpiled languages. Languages like TypeScript, CoffeeScript, even ECMAScript 6, and how they have impacted and will affect JavaScript development in the future.

Part III. Building Your First Modern JavaScript App With Angular 2 will wrap up the book with a practical look at building modern JavaScript applications. Angular 2 is a great framework for this purpose because it takes advantage of all modern web standards, ES6 and has a very compact design that makes writing Angular 2 apps feel like writing vanilla JavaScript. That is, you won’t need to spend a lot of time learning convoluted framework concepts, and will focus instead in developing your JavaScript skills to build a real app killing two birds with one stone (Muahahaha!).

In regards to the size and length of each chapter, aside from the introduction, I have kept every chapter small. The idea being that you can learn little by little, acquire a bit of knowledge that you can apply in your daily work, and get a feel of progress and completion from the very start.

Understanding the Code Samples in This Book

How to Run the Code Samples in This Book

For simplicity, I recommend that you start running the code samples in the browser. That’s the most straightforward way since you won’t need to install anything in your computer. You can either type them as you go in the browser JavaScript console (F12 for Chrome if you are running windows or Opt-CMD-J in a Mac) or with prototyping tools like JsBin, jsFiddle, CodePen or Plunker. Any of these tools is excellent so you can pick your favorite.

If you don’t feel like typing, all the examples are available in jsFiddle/jsBin JavaScriptmancy library: http://bit.ly/javascriptmancy-samples.

For testing ECMAScript 6 examples I recommend JsBin, jsFiddle or the Babel REPL at https://babeljs.io/repl/. Alternatively there’s a very interesting Chrome plugin that you can use to run both ES5 and ES6 examples called ScratchJS.

If you like, you can download all the code samples from GitHub and run them locally in your computer using node.js.

Also keep an eye out for javascriptmancy.com where I’ll add interactive exercises in a not too distant future.

A Note About Conventions Used in the Code Samples

The book has three types of code samples. Whenever you see a extract of code like the one below, where statements are preceded by a >, I expect you to type the examples in a REPL.

The code after > is what you need to type and the expression displayed right afterwards is the expected result:

1 > 2 + 2
2 // => 4  

Some expressions that you often write in a REPL like a variable or a function declaration evaluate to undefined:

1 > var hp = 100;
2 // => undefined

Since I find that this just adds unnecessary noise to the examples I’ll omit these undefined values and I’ll just write the meaningful result. For instance:

1 > console.log('yippiiiiiiii')
2 // => yippiiiiiiii
3 // => undefined     <==== I will omit this

When I have a multiline statement, I will omit the > so you can more easily copy and paste it in a REPL or prototyping tool (jsBin, CodePen, etc). That way you won’t need to remove the unnecessary > before running the sample:

1 let createWater = function (mana){
2     return `${mana} liters of water`;
3 }

I expect the examples within a chapter to be run together, so sometimes examples may reference variables from previous examples within the same section. I will attempt to show smallish bits of code at a time for the sake of simplicity.

For more advanced examples the code will look like a program, there will be no > to be found and I’ll add a filename for reference. You can either type the content of the files in your favorite editor or download the source directly from GitHub.

 1 export class Doom {
 2   constructor(){
 3     /* Oh no! You read this...
 4     /
 5     /  I am sorry to tell you that in 3 days
 6     /  at midnight the most horrendous apparition
 7     /  will come out from your favorite dev machine
 8     /  and it'll be your demise
 9     /  that is... 
10     /  unless you give this book as a gift to 
11     /  other 3 developers, in that case you are 
12     /  blessed for ever and ever
13     */
14   }
15 }

A Note About the Exercises

In order to encourage you to experiment with the different things that you will learn in each chapter I wrap every single one of them with exercises.

It is important that you understand that there is almost no wrong solution. I invite you to let your imagination free and try to experiment and be playful with your new found knowledge to your heart’s content. I do offer a solution for each exercise but more as a guidance and example that as the one right solution.

In many of the exercises you’ll see the following pattern:

1 // mooleen.weaves('some code here');
2 mooleen.weaves('teleport("out of the forest", mooleen, randalf)');

This is completely equivalent to:

1 // some code here
2 teleport("out of the forest", mooleen, randalf);

I just use a helper function weaves to make it look like Moolen, the mighty wizard is casting a spell (in this case teleport).

A Note About ECMAScript 5 and ECMAScript 6,7 within The Book

Everything in programming has a reason for existing. That hairy piece of code that you wrote seven months ago, that feature that went into an application, that syntax or construct within a language, all were or seemed like good ideas at the time. ES6, ES7 and future versions of JavaScript all try to improve upon the version of JavaScript that we have today. And it helps to understand the pain points they are trying to solve, the context in which they appear and in which they are needed. That’s why this book will show you ES5 in conjunction with ES6 and beyond. For it will be much easier to understand new features when you see them as a natural evolution of the needs and pain points of developers today.

How will this translate into the examples within the book? - you may be wondering. Well I’ll start in the beginning of the book writing ES5 style code, and slowly but surely, as I go showing you ES6 features, we will transform our ES5 code into ES6. By the end of the book, you yourself will have experienced the journey and have mastered both ES5 and ES6.

Additionally, it is going to take some time for us to start using ES6 to the fullest, and there’s surely a ton of web applications that will never be updated to using ES6 features so it will be definitely helpful to know ES5.

A Note About the Use of Generalizations in This Book

Some times in the course of the book I will make generalizations for the sake of simplicity and to provide a better and more continuous learning experience. I will make statements such as:

In JavaScript, unlike in C#, you can augment objects with new properties at any point in time

If you are experienced in C# you may frown at this, cringe, raise your fist to the sky and shout: Why!? oh Why would he say such a thing!? Does he not know C#!?. But bear with me. I will write the above not unaware of the fact that C# has the dynamic keyword and the ExpandoObject class that offer that very functionality, but because the predominant use of C# involves the use of strong types and compile-time type checking. The affirmation above provides a much simpler and clearer explanation about JavaScript than writing:

In JavaScript, unlike in C# where you use classes and strong types in 99% of the situations and in a similar way to the use of dynamic and ExpandoObject, you can augment objects with new properties at any point in time

So instead of focusing on being correct 100% of the time and diving into every little detail, I will try to favor simplicity and only go into detail when it is conductive to understanding JavaScript which is the focus of this book. Nonetheless, I will provide footnotes for anyone that is interested in exploring these topics further.

Do You Have Any Feedback? Found Any Error?

If you have any feedback or have found some error in this book that you would like to report, then don’t hesitate to drop me an email at jaime@vintharas.com.

A Final Word From the Author

The goal for this series of books is to be holistic. Holistic enough to give a good overview of the JavaScript language and ecosystem, yet contain enough detail to impart real knowledge about how JavaScript really works. That’s a fine line to tread and sometimes I will probably cover too little or too much. If so don’t hesitate to let me know. The beauty of a lean published book is that I have much more room to include improvements suggested by you.

There is a hidden goal as well, that is to make it as fun and enjoyable as possible. Therefore the fantasy theme of the whole book, the conversational style, the jokes and the weird sense of humor. Anyways, I have put my heart and soul into this book and hope you really enjoy it!

Jaime, 2015

Tome I. Mastering the Arcane Art of JavaScript-mancy

Introduction

For many years JavaScript has been frowned upon and looked down on by many developers due to its quirky nature, obscure behaviors and many WTFs that populate its hairy APIs and operations.

Frown upon no more! For with modern design patterns, libraries, tools and the long awaited ECMAScript 6 (ES6, ES2015) writing JavaScript is now a pleasure.

Join me at the school of JavaScript-mancy as we travel along the modern landscape of writing JavaScript in 2015 and beyond, as we discover the organic evolution of this beautiful language and its thriving ecosystem, and delve in the latest features/spells/incantations of the JavaScript Arcana.

You my friend, can no longer ignore JavaScript. JavaScript is the most deployed language on earth, a beautiful and expressive language that supports many paradigms and which has a thriving community that continuously expands and improves its ecosystem with patterns, libraries, frameworks and tools. You don’t want to miss this train.

But JavaScript, though forgiving and specially conceived to be easy to learn, can be either daunting for us that have a strongly-typed mindset and come from languages such as C# or Java or, more often, laughed at as a toy.

For you who consider it daunting and hate working with it worry not! I will show you the most common misconceptions and all the patterns you need to know to become as fluent in JavaScript as you are in C#.

For you who consider it a toy language, something associated not with real programming but with copy-paste coding or scripting to add flare to websites, I will show you all the different patterns and programming paradigms that JavaScript supports and which make it just as good and powerful as C#.

Let’s get started!

Once Upon a Time…

Once upon a time, in a faraway land, there was a beautiful hidden island with captivating white sandy beaches, lush green hills and mighty white peaked mountains. The natives called it Asturi and, if not for an incredible and unexpected event, it would have remained hidden and forgotten for centuries.

Some say it was during his early morning walk, some say that it happened in the shower. Be that as it may, Branden Iech, at the time the local eccentric and today considered the greatest Philosopher of antiquity, stumbled upon something that would change the world forever.

In talking to himself, as both his most beloved companions and his most bitter detractors would attest was a habit of his, he stumbled upon the magic words of JavaScript and the mysterious REPL.

In the years that followed he would teach the magic word and fund the order of JavaScriptmancers bringing a golden age to our civilization. Poor, naive philosopher. For such power wielded by mere humans was meant to be misused, to corrupt their fragile hearts and bring their and our downfall. It’s been ten thousand years, ten thousand years of wars, pain and struggle.

It is said that, in the 12th day of the 12th month of the 12th age a hero will rise and bring balance to the world. That happens to be today.

12th Age, Guardian of Chronicles

This book has a story in it. It is a story of a fantasy¹ world where some people can wield JavaScript to affect the world around them, to essentially program the world and bend it to their will. Cool right? The story follows the step of a heroine that comes to this hypothetical world to save it from evil, but of course, she needs to learn JavaScript first. Care to join her in her quest to learn JavaScript and save the world?

The Essential Ingredients Of JavaScript-Mancy

The importance of the fundamentals cannot be enough overstated,  
the gathering of the proper ingredients for an incantation,  
the carefulness and caring of the preparations,  
the timing and intimate knowledge of the rituals,  
everything affects the end result.

To practice is to be,  
practice as you want to be,  
for do you want to be an Artful Wizard, or a mediocre one?  
  
        - Kely Sompsin,
        Maester of the Guild, 
        Fourth Age  

An Introduction to JavaScript-Mancy

I expect the reader of this manuscript to be well acquainted with the basics of programming, but I couldn’t, in good faith, start the book without some sort of introduction to the arts of JavaScript. This first chapter will therefore take you through the whole breadth of the JavaScript language, albeit in a superficial way. I will show you all the basic features of JavaScript, even those of its latest incarnation ECMAScript 6, and how they differ or are similar to C#. I abhorr starting programming books with page after page on for loops and if statements so I will attempt to be as brief, interesting and entertaining as I can.

If you feel like you are well versed in the basics of JavaScript (and the new ES6 features) then by all means jump over this chapter, but be aware that there’s a story happening in the examples, so you might be interested in taking a look. In any case, here we go…

JavaScript

JavaScript, as we the guardians of JavaScript-mancy usually call the arts, is a multi-paradigm dynamic programming language. The multi-paradigm bit means that JavaScript lends itself well to different styles (paradigms) of programming like object-oriented or functional programming. The dynamic part means that… well the dynamic part is widely disputed even today… but for all intents and purposes we can say that JavaScript is evaluated as it is executed, there’s no compilation step in which variables are bound, types are checked and expressions analyzed for correctness. The JavaScript runtime defers all this work until the code itself is being executed and this allows for a lot more freedom and interesting applications like metaprogramming ².

JavaScript is also dynamically typed so a variable can reference many different types during its lifetime and you can augment objects with new methods or properties at any point in time.

I can, for example, summon a minion from the depths of hell using the var keyword and let it be a number:

1 > var minion = 1
2 > minion
3 // => 1

And I can do some alchemy thereafter and transform the minion into something else, a string, for example:

1 > minion = "bunny";
2 // => "bunny"

I can keep doing that for as long as I want (as long as I have enough mana³ of course), so let’s make my minion an object:

1 > minion = {name: 'bugs', type: 'bunny'};
2 // => Object {name: 'bugs', type: 'bunny'}

In JavaScript I don’t need a class to create an object. I can just create an object with whichever properties I desire and then later on augment ⁴ it with new properties to my heart’s content:

1 > minion.description = 'A mean looking bunny';
2 > console.log(minion);
3 // => Object {name: bugs, type: bunny, 
4 //            description: A mean looking bunny}

JavaScript Has Some Types

JavaScript supports the following types: Number, String, Object, Boolean, undefined, null and Symbol.

As you may have guessed, JavaScript has a single type to represent all numbers. Which is pretty nice if you ask me, not having to ever think about doubles, and shorts, and longs and floats…

1 > var one = 1
2 > typeof(one)
3 // => "number"
4 
5 > var oneAndAHalf = 1.5
6 > typeof(1.5)
7 // => "number"

There’s a string type that works as you would expect any respectable string to behave. It lets you create string literals. Interestingly enough, JavaScript strings support both single (') and double quotes ("):

1 > var text = "Thou shalt not pass!"
2 > typeof text
3 // => "string"
4 
5 > var anotherBitOfText = 'No! Thou Shalt Not Pass!'
6 > typeof anotherBitOfText
7 // => "string"

JavaScript also has a boolean type to represent true and false values:

1 > var always = true
2 > var never = false
3 > typeof(always)
4 // => "boolean"

And an object type that we can use to create any new custom types:

1 > var skull = {name: 'Skull of Dark Magic'}
2 > typeof(skull)
3 // => object

JavaScript differs from other languages in that it has two different ways of representing the lack of something. Where C# has null, JavaScript has both null and undefined. Unlike in C#, the default value of anything that hasn’t been yet defined is undefined, whereas null must be set explicitly.

1 > skull.description
2 // => undefined
3 > typeof(skull.description)
4 // => undefined
5 
6 > skull.description = null;
7 > typeof(skull.description)
8 // => object :) 

This can get even more confusing because of the fact that there’s a third possibility. That a variable hasn’t been declared:

1 > abracadabra
2 // => Uncaught ReferenceError: abracadabra is not defined

The confusion coming mainly from the error message: abracadabra is not defined. You can just think about these variables as undeclared instead of not defined and stick to the previous definition of undefined.

ECMAScript 6 brings a new primitive type, the symbol. Symbols can be seen as constant and immutable tokens that can be used as unique IDs.

1 > var crux = Symbol()
2 > typeof(crux)
3 // => symbol

Later within the book, we’ll see how we can use Symbols to enable new patterns for hiding data in JavaScript.

Everything Within JavaScript Behaves Like an Object

In spite of JavaScript not having the concept of value types or reference types, numbers, strings and booleans behave like C# value types and objects behave like C# reference types. In practice, however, everything within JavaScript can be treated as an object.

Numbers for instance, provide several useful methods:

1 > (1).toString()
2 // => 1
3 > (3.14159).toPrecision(3)
4 // => 3.141
5 > (5000).toLocaleString('sv-SE')
6 // => 5 000

And so do strings:

1 > "a ghoul".toUpperCase()
2 // "A GHOUL"

Interesting right? If a number is a primitive value type, how come it has methods? Well, what is happening is that, whenever we call a method on a number or other primitive type, the JavaScript runtime is wrapping the primitive value in a special wrapper object. So even though 1 is not an object itself, when JavaScript evaluates (1).toPrecision(3) it wraps the value within the Number object on-the-fly. You can test the reverse process and instantiate a number using the wrapper object directly:

1 > var number = new Number(1);
2 // => Number {}
3 > typeof(number)
4 // => 'object'

Then unwrap the original value with valueOf:

1 > number.valueOf()
2 // => 1

Even more remarkable than numbers and strings, functions behave like objects. They have their own methods:

1 > var fireBall = function(){ world.spell('A blazing ball of fire mat\
2 erializes from the palm of your hand!');};
3 > fireBall.apply
4 // => function apply(){}

And you can even add properties to a function:

1 {lang="javascript"}
2 > fireBall.maxNumberOfCharges = 5
3 // => 5;
4 > fireBall.maxNumberOfCharges
5 // => 5;

Let’s take a quick look at each one of these types and how they work in JavaScript.

Strings in JavaScript

Strings, like in C#, let you represent text literals.

1 > "hi there"
2 // => hi there
3 > "creepy"
4 // => creepy
5 > "stop repeating what I say"
6 // => stop repeating what I say

Unlike in C# you can use both single (') and double quotes (") to create a string. Oftentimes you will see one used to escape the other:

1 > "this ain't cool man"
2 // => this ain't cool man
3 > 'you think you are so "funny"'
4 // => you think you are so "funny"

Any string has a number of useful methods:

1 > "I am tired of you devious REPL".split(' ');
2 // => ["I", "am", "tired", "of", "you", "devious", "REPL"]
3 > "I am tired of you devious REPL".replace('tired', 'ecstatic');
4 // => I am ecstatic of you devious REPL
5 > "I am tired of you devious REPL".indexOf('tired');
6 // => 5

ES6 also brings a number of new methods like startsWith, endsWith, repeat:

1 > "Stop REPL!".startsWith("Stop");
2 // => true
3 > "Stop REPL!".endsWith("REPL!");
4 // => true
5 > "NaN".repeat(10) + " BatMan!!!"
6 // => NaNNaNNaNNaNNaNNaNNaNNaNNaNNaN BatMan!!!!
7 > "ha! Now I beat you at your own game!"
8 // => "ha! Now I beat you at your own game!"

Until recently, there was no such thing as C# String.format nor StringBuilder so most injecting values in strings was done using the + operator or string.concat:

1 > var target = 'minion';
2 > "obliterate " + target + " with hellfire!"
3 // => obliterate minion with hellfire!
4 > "obliterate ".concat(target, " with hellfire!")
5 // => obliterate minion with hellfire!

Fortunately, ES6 brings template strings and a more elegant approach to string interpolation.

Better String Interpolation ES6 Template Strings

The new ES6 Template Strings improve greatly the way you can operate with strings. They allow string interpolation based on the variables that exist in the scope where the template is evaluated, thus providing a much cleaner and readable syntax.

In order to create a template string you surround the string literal with backticks and use ${variable-in-scope} to specify which variable to include within the resulting string:

1 > var spell = 'hellfire';
2 > `obliterate ${target} with ${spell}!`
3 // => obliterate minion with hellfire!

Template strings also let you easily create multi-line strings.

Where in the past you were forced to make use of string concatenation and the new line character \n:

1 > "One ring to rule them all\n" +
2   "One ring to find them;\n" +
3   "One ring to bring them all\n" +
4   "and in the darkness bind them"
5 // =>  One ring to rull them all
6 //     One ring to find them;
7 //     One ring to bring them all
8 //     and in the darkness bind them

ES6 Template strings let you write a multi-line string in a more straightforward fashion:

1 > `One ring to rull them all
2   One ring to find them
3   One ring to bring them all
4   and in the darkness bind them`
5 // =>  One ring to rull them all
6 //     One ring to find them;
7 //     One ring to bring them all
8 //     and in the darkness bind them

Functions in JavaScript

Functions are the most basic building component in JavaScript. As such, they can live more independent lives than methods in C# which are always tied to a class. So, you’ll oftentimes see functions alone in the wild:

1 > function obliterate(target){ 
2     console.log(`${target} is obliterated into tiny ashes`);
3 }
4 > obliterate('rabid bunny')
5 // => rabid bunny is obliterated into tiny ashes

JavaScript, in a radically different way than C#, lets you call a function with any number of arguments, even if they are not defined in a function’s signature:

1 > obliterate('rabid bunny', 'leprechaun', 'yeti')
2 // => rabid bunny is obliterated into tiny ashes

And even with no arguments at all, although depending on the function implementation it may cause some chaos and some mayhem:

1 > obliterate()
2 // => undefined is obliterated into tiny ashes

You can use the very special arguments array-like object to get hold of the arguments being passed at runtime to a given function:

1 > function obliterateMany(){
2     // ES6 method to convert arguments to an actual array
3     var targets = Array.from(arguments).join(', ');
4     console.log(`${targets} are obliterated into tiny ashes`);
5 }
6 > obliterateMany('Rabid bunny', 'leprechaun', 'yeti')
7 // => Rabid bunny, leprechaun, yeti are obliterated into tiny ashes

Or the finer ES6 rest syntax reminescent of C# params:

1 > function obliterateMany(...targets){
2     console.log(`${targets} are obliterated into tiny ashes`);
3 }
4 > obliterateMany('Rabid bunny', 'leprechaun', 'yeti')
5 // => Rabid bunny, leprechaun, yeti are obliterated into tiny ashes

In addition to functions working as… well… functions, they perform many other roles in JavaScript and are oftentimes used as building blocks to achieve higher-order abstractions: they are used as object constructors, to define modules, as a means to achieve data hiding and have many other uses.

ES6 changes this complete reliance on functions a little bit as it provides new higher level constructs that are native to the language, constructs like ES6 classes and ES6 modules which you’ll be able to learn more about later in this series. Indeed throughout this series I’ll show you both ES5 constructs, the present and the past, and ES6 ones, the present-ish and the future, so you’ll feel at home in any JavaScript codebase you happen to work with.

Functions as Values

An interesting and very important aspect of functions in javascript is that they can be treated as values, this is what we mean when we say functions are first-class citizens of the language. It means that they are not some special construct that you can only use in certain places, with some special conditions and grammar. Functions are just like any other type in JavaScript, you can store them in variables, you can pass them as arguments to other functions and you can return them from a function.

For instance, let’s say you want to create a very special logger that prepends your name to any message that you wish to log:

1 > var log = function(msg){ console.log(msg);}
2 > var logByRandalf = function (msg, logFn){
3     logFn(`Randalf logs: ${msg}`);
4 }
5 > logByRandalf('I am logging something, saving it to memory for ever\
6 ', log);
7 // => Randalf logs: I am logging something, saving it to memory for \
8 ever

But that was a little bit awkward, what if we return a function with the new functionality that we desire:

 1 > var createLogBySomeone = function (byWho){
 2     return function(msg){
 3         return console.log(`${byWho} logs: ${msg}`);
 4     };
 5 }
 6 > var logByRandalf = createLogBySomeone('Randalf');
 7 > logByRandalf('I am logging something, saving it to memory for ever\
 8 ');
 9 // => Randalf logs: I am logging something, saving it to memory for \
10 ever

If you feel a little bit confused by this don’t worry, we will dive deeper into functional programming, closures and high-order functions later in the series. For now just realize that functions are values and you can use them as such.

JavaScript Has Function Scope

Another very interesting aspect of JavaScript that is diametrically opposed to how things work in C# is the scope of variables. JavaScript variables have function scope and not block scope. This means that functions define new scopes for variables and not blocks of code (if statements, for loops, code between {}, etc…) which highlights once more the importance of functions in JavaScript.

You can appreciate function scope in all its glory in these examples. First if you declare a single function with an if block you can verify how the if block doesn’t define a new scope as you would expect in C#:

1 > function scopeIsNuts(){ // new scope for scopeIsNuts
2     console.log(x); // => undefined
3     if (true){
4         var x = 1;
5     }
6     console.log(x); // => 1
7 }

But if we replace the if block with a new function inner, then we have two scopes:

 1 > function outer(){ // new scope for outer
 2     var x = 0;
 3     console.log(x); // => 0
 4 
 5     function inner(){ // new scope for inner
 6         var x = 1;
 7         console.log(x); // => 1
 8     }
 9     inner();
10 
11     console.log(x); // => 0
12 }

ES6 let, ES6 const and Block Scope

ES6 attemps to bring an end to the confusion of JavaScript having function scope with the let keyword that allows you to create variables with block scope. With ES6 you can either use var for function scoped variables or let for block scoped ones.

If you rewrite the example we used to illustrate function scope with let, you’ll obtain a very different result:

1 > function scopeIsNuts(){ // new scope for scopeIsNuts
2     console.log(x); // => undefined
3     if (true){
4         let x = 1;
5         console.log(x); // => 1
6     }
7     console.log(x); // => undefined
8 }

Now the x variable only exists within the if statement block. Additionally, you can use the const keyword to declare constant variables with block scope.

1 > function scopeIsNuts(){ // new scope for scopeIsNuts
2     console.log(x); // => undefined
3     if (true){
4         const x = 1;
5         console.log(x); // => 1
6         x = 2; // => TypeError
7     }
8     console.log(x); // => undefined
9 }

ES6 Default Arguments

ES6 finally brings default arguments to JavaScript functions, and they work just like in C#:

 1 > function fireBall(target, mana=10){
 2    var damage = 1.5*mana;
 3    console.log(`A huge fireball springs from 
 4 your fingers and hits the ${target} with ${damage} damage`);
 5 }
 6 > fireBall('troll')
 7 // => A huge fireball springs from your fingers and hits the troll 
 8 //    with 15 damage
 9 > fireBall('troll', /* mana */ 50)
10 // => A huge fireball springs from your fingers and hits the troll 
11 //    with 75 damage

ES6 Destructuring

Another nifty ES6 feature is destructuring. Destructuring lets you unwrap any given object into a number of properties and bind them to variables of your choice. You can take advantage of destructuring with any object:

1 > var {hp, defense} = {
2     name: 'conan', 
3     description: 'cimmerian barbarian king of thieves', 
4     hp: {current: 9000, max: 9000}, 
5     defense: 100, attack: 400};
6 > console.log(hp);
7 // => {current: 9000, max: 9000}
8 > console.log(defense);
9 // => 100

Even when passing an object to a function:

 1 function calculateDamage({attack}, {hp, defense}){
 2   var effectiveAttackRating = attack - defense + getHpModifier(hp);
 3   var damage = attackRoll(effectiveAttackRating);
 4   return damage > 0 ? damage: 0;
 5 
 6   function getHpModifier(hp){ 
 7     return hp.current < 0.1*hp.max ? 10 : 0;
 8   }
 9 
10   function attackRoll(dice){ 
11     // do some fancy dice rolling 
12     return dice; 
13   } 
14 }
15 
16 var troll = {
17   name: 'Aaagghhhh', 
18   description: 'nasty troll', 
19   hp: {current: 20000, max: 20000}, 
20   defense: 40, attack: 100
21 };
22 var conan = {name: 'conan', 
23   hp: {current: 200, max: 200}, 
24   defense: 1000, attack: 1000
25 };
26 console.log(calculateDamage(troll, conan));
27 // => 0
28 // => no troll gonna damage conan

ES6 Arrow Functions

Another great feature brought by ES6 are arrow functions which resemble C# lambda expressions. Instead of writing the obliterate function as we did before, we can use the arrow function syntax:

 1 /* 
 2 > function obliterate(target){ 
 3     console.log(`${target} is obliterated into tiny ashes`);
 4 }
 5 */
 6 > let obliterate = target => 
 7     console.log(`${target} is obliterated into tiny ashes`);
 8 > obliterate('minion');
 9 // => minion is obliterated into tiny ashes
10 > obliterate('rabid bunny')
11 // => rabid bunny is obliterated into tiny ashes

And if you have a function with more arguments or statements, you can write it just like we do in C#:

1 > let obliterateMany = (...targets) => {
2     targets = targets.join(', ');
3     console.log(`${targets} are obliterated into tiny ashes`);
4 };
5 > obliterateMany('bunny', 'leprechaun', 'yeti');
6 // => Bunny, leprechaun, yeti are obliterated into tiny ashes

We will dive deeper into arrow functions later in the book and see how they not only provide a terser and more readable syntax but also serve a very important function in what regards to safekeeping the value of this in JavaScript. (We’ve got ourselves a very naughty this in JavaScript as you’ll soon appreciate yourself)

OOP and Objects in JavaScript

JavaScript has great support for object-oriented programming with objects literals, constructor functions, prototypical inheritance, ES6 classes and less orthodox OOP paradigms like mixins and stamps.

Objects in JavaScript are just key/value pairs. The simplest way to create an object is using an object literal:

 1 > var scepterOfDestruction = {
 2     description: 'Scepter of Destruction',
 3     toString: function() { 
 4         return this.description; 
 5     },
 6     destruct: function(target) { 
 7         console.log(`${target} is instantly disintegrated`);
 8     }
 9 }
10 > scepterOfDestruction.destruct('apple');
11 // => apple is instantly disintegrated

ES6 makes easier to create object literals with syntactic sugar for functions also known as method shorthand:

1 > var scepterOfDestruction = {
2     description: 'Scepter of Destruction',
3     toString() { 
4         return this.description; 
5     },   
6     destruct(target) { 
7         console.log(`${target} is instantly disintegrated`);
8     }
9 }

And for creating properties from existing variables also known as property shorthand:

 1 > var damage = 10000;
 2 > var scepterOfDestruction = {
 3     description: 'Scepter of Destruction', 
 4     damage, // as opposed to damage: damage
 5     toString() { 
 6         return this.description; 
 7     },    
 8     destruct(target) { 
 9         console.log(`${target} is instantly disintegrated`);
10     }
11 }
12 > scepterOfDestruction.damage;
13 // => 10000

This works great for one-off objects. When you want to reuse the same type of object more than once you can either use a vanilla factory method or a constructor function with the new keyword:

 1 // by convention constructor functions are capitalized
 2 > function Scepter(name, damage, spell){
 3     this.description = `Scepter of ${name}`,
 4     this.damage = damage;
 5     this.castSpell = spell;
 6     this.toString = () => this.description;
 7 }
 8 > var scepterOfFire = new Scepter('Fire', 100, 
 9     (target) => console.log(`${target} is burnt to cinders`));
10 > scepterOfFire.castSpell('grunt');
11 // => grunt is burnt to cinders

Prototypical Inheritance

Yet another big diffence between C# and JavaScript are their inheritance models. JavaScript exhibits what is known as prototypical inheritance. That means that objects inherit from other objects which therefore are called prototypes. These objects create what is known as a prototypical chain that is traversed when the JavaScript runtime tries to determine where in the chain a given method is defined.

Let’s say that you have an object that represents an abstraction for any item that can exist in your inventory:

1 > var item = {
2    durability: 100,
3    sizeInSlots: 1,
4    toString(){ return 'an undescriptive item';}
5 }
6 > item.toString();
7 // => an undescriptive item

And a two handed iron sword that in addition to being an item (and an awesome item at that) has its own specific set of traits:

 1 > var ironTwoHandedSword = {
 2     damage: 60,
 3     sizeInSlots: 2,
 4     wield() { 
 5       console.log('you wield your iron sword crazily over your head'\
 6 );
 7     },
 8     material: 'iron',
 9     toString() {return 'A rusty two handed iron sword';}
10 };

You can take advantage of JavaScript prototypical inheritance to reuse the item properties across many items, by setting the item object as the prototype⁵ of the ironTwoHandedSword (and any other specific items that you create afterwards).

1 > Object.setPrototypeOf(ironTwoHandedSword, item);

This will establish a prototypical chain, so that, if we attempt to retrieve the sword durability, the JavaScript runtime will traverse the chain and retrieve the property from the item prototype:

1 > ironTwoHandedSword.durability;
2 // => 100

If, on the other hand, you attempt to access a property that exists in both the prototype and the object itself, the nearest property in the chain will win:

1 > ironTwoHandedSword.toString();
2 // => A rusty two handed iron sword

ES6 exposes the __proto__ property that lets you directly assign a prototype through an object literal:

1 > var ironTwoHandedSword = {
2     __proto__: item,
3     damage: 60,
4     // etc...
5 };
6 > ironTwoHandedSword.prototype = item;

There’s a lot more to prototypical inheritance and the many different OOP paradigms supported by JavaScript. But we’ll look into them further later in the series.

ES6 Classes

A new addition to JavaScript you might have heard about and celebrated are ES6 classes. The existence of ES6 classes doesn’t mean that JavaScript gets classes just like C# and we’re not going to worry about constructor functions and prototypical inheritance anymore. ES6 classes are “just” syntactic sugar over the existing inheritance model and the way we craft objects in JavaScript. That being said, it is a great declarative way to represent constructor/prototype pairs.

A JavaScript class looks very similar to a C# class:

 1 class Item {
 2   constructor(durability = 100, sizeInSlots = 1){
 3     this.durability = durability;
 4     this.sizeInSlots = sizeInSlots;
 5   }
 6   toString(){ 
 7     return 'an undescriptive item';
 8   }
 9 }
10 var item = new Item();
11 item.toString();
12 // => an undescriptive item

And so does inheritance:

 1 class Sword extends Item {
 2   constructor(durability = 500, sizeInSlots = 2, 
 3               damage = 50, material = 'iron'){
 4     super(durability, sizeInSlots);
 5     this.damage = damage;
 6     this.material = material;
 7   }
 8   wield() { 
 9     console.log(`you wield your ${this.material} sword
10 crazily over your head`);
11   }
12   toString() {
13     return `A ${this.material} sword`;
14   }
15 };
16 var sword = new Sword();
17 sword.wield();
18 // => you wield your iron sword crazily over your head

Arrays, Maps and Sets in JavaScript

Up until recently JavaScript had only one single data structure, albeit very verstatile, to handle collections of items: the array. You can create an array using using square brackets []:

1 > [1, 2, 3, 4 ,5]
2 // => [1,2,3,4,5]

You can mix and match the different elements of an array. There’s no type restrictions so you can have numbers, strings, objects, functions, arrays, etc… in much the same way that you can find the most strange items in a kender’s ⁶ pouch:

1 > var aKendersPouch = [
2     'jewel', 
3     '3 stones', 
4      1, 
5     {name: 'Orb of Power'}, 
6     function() { return 'trap!';}
7     ];

You can access the items of an array via their indexes:

1 > aKendersPouch[0]
2 // => jewel
3 > aKendersPouch[4]()
4 // => trap!

You can also traverse the indexes of an array using the for/in loop:

1 > for (var idx in aKendersPouch) console.log(aKendersPouch[idx]);
2 // => jewel
3 // => 3 stones
4 // => ...etc
5 // => function() { return 'trap!';}

And even better the items of an array using ES6 for/of loop:

1 > for (var item of aKendersPouch) console.log(item); 
2 // => jewel
3 // => 3 stones
4 // => ...etc
5 // => function() { return 'trap!';}

Arrays have a lot of cool and useful methods that you can use to add/remove or otherwise operate on the items within the array:

 1 > aKendersPouch.length
 2 // => 5
 3 
 4 // add item at the end of the array
 5 > aKendersPouch.push('silver coin');  
 6 // => 6 (returns the current length of the array)
 7 > aKendersPouch.push('6 copper coins', 'dental floss');
 8 // => 8
 9 
10 // pop item at the end of the array
11 > aKendersPouch.pop(); 
12 // => dental floss
13 
14 // insert item at the beginning
15 > aKendersPouch.unshift('The three Musketeers'); 
16 // => 8
17 
18 // extract item from the beginning of the array
19 > aKendersPouch.shift(); 
20 // => 'The three musketeers'

And even LINQ-like methods to perform functional style transformations within an array:

 1 > const isValuable = item => parseInt(item) > 5;
 2 > const toGoldCoins = item => parseInt(item) || 0;
 3 > const sumCoins = (sum, price) => sum + price;
 4 
 5 > var goldCoins = aKendersPouch
 6                      .filter(isValuable) // ES6 analogous to LINQ Wh\
 7 ere
 8                      .map(toGoldCoins) // analogous to LINQ Select
 9                      .reduce(sumCoins, 0); // analogous to LINQ Aggr\
10 egate
11 > console.log(goldCoins);
12 // => 6

You will learn a ton more about arrays later in the book.

ES6 Spread Operator and Arrays

The ES6 spread operator can also be used to merge or flatten an array within another array:

1 > var newRecruits = ['Sam', 'John', 'Connor'];
2 > var merryBandits = ['Veteran Joe', 'Brave Krom', ...newRecruits];
3 > merryBandits;
4 // => ["Veteran Joe", "Brave Krom", "Sam", "John", "Connor"]

ES6 Maps and Sets

ES6 gives us magicians two new data structures to work with: maps, a true key/value pair data structure and sets to handle collections of unique items.

You can create a new map using the Map constructor:

1 > var libraryOfWisdom = new Map();
2 > libraryOfWisdom.set('A', 
3    ['A brief history of JavaScript-mancy', 'A Tale of Two Cities']); 
4 > libraryOfWisdom.get('A')
5 //=> ['A brief history of JavaScript-mancy', 'A Tale of Two Cities']\
6 ; 

You can even seed a map with existing information by sending an array of key/value pairs⁷:

1 > var libraryOfWisdom = new Map([
2  ['A', ['A brief history of JavaScript-mancy', 'A Tale of ...']],
3  ['B', ['Better Dead Than Powerless: Tome I of Nigromantics']]
4 ]);
5 > libraryOfWisdom.get('B');
6 // => ['Better Dead Than Powerless: Tome I of Nigromantics']

In a similar fashion, you create sets using the Set constructor:

1 > var powerElements = new Set(['earth', 'fire', 'water', 'wind']);
2 > powerElements
3 // => Set {"earth", "fire", "water", "wind"}

Sets will ensure that you don’t have duplicated data within a collection:

1 > powerElements.add('water').add('earth').add('iron');
2 > console.log(powerElements);
3 // => Set {"earth", "fire", "water", "wind", "iron"}

JavaScript Flow Control

JavaScript gives you the classic flow control structures that you are accustomed to: if, for, while loops behave much in the same way in JavaScript than in C# (but for the function scoped variables of course).

In addition to these, JavaScript has the for/in loop that lets you iterate over the properties of an object:

 1 > var spellOfFarseeing = 
 2     { name: 'Spell of Farseeing', 
 3       manaCost: 10, 
 4       description: 'The spell lets you see a limited' + 
 5                    'portion of a far away location;'}
 6 
 7 > for (var prop in spellOfFarseeing) {
 8     console.log(`${prop} : ${spellOfFarseeing[prop]}`);
 9 }
10 // => name : Spell of Farseeing
11 // => manaCost : 10
12 // => description : The spell lets you see a limited 
13 // portion of a far away location

And the ES6 for/of loop that lets you iterate over collections⁸ (arrays, maps and sets):

1 > for (var element of powerElements) console.log(element);
2 // => earth
3 // => fire
4 // => water
5 // => etc...

Logical Operators in JavaScript

Abstract Equality and Strict Equality

JavaScript equality operators behave in a particularly special way. The operators that you are accustomed to use in C# == and != are called abstract equality operators and evaluate the equality of expressions in a loose way. If the two expressions being evaluated by one of these operators don’t match in type, they’ll be converted to a matching type. For instance, in evaluating the abstract equality of 42 and "42", the string will be converted to a number resulting in both values being equal:

1 > 42 == '42'
2 ==> true

Fortunately JavaScript also provides operators that performs strict equality ( === and !==) which is basically a comparison of two values without the implicit type conversion.

1 > 42 === '42'
2 ==> false

Implicit Type Conversion Also Known As Type Coercion

This implicit conversion that takes place in JavaScript gives birth to the concept of truthy and falsey. Since any value can be evaluated as a boolean, we say that some values like an array [] or an object {} are truthy, and some other values like empty string '' or undefined are falsey. In the examples below we use the !! to explicitly convert values to boolean for clarity purposes:

 1 > !![]
 2 // => true
 3 > !!{}
 4 // => true
 5 > !!""
 6 // => false
 7 > !!undefined
 8 // => false
 9 > !!null
10 // => false
11 > !!0
12 // => false

This allows for a terser way to write if statements

1 > if (troll) // as opposed to (troll != null && troll != undefined)

Since troll is coerced to a boolean type, having the troll variable holding an object value will evaluate to truthy and having it holding null or undefined will be falsey. In either case the if statement will fulfill its purpose while being much nicer to read.

OR and AND

OR (||) and AND (&&) operations also behave in an interesting way. The OR operation will return the first truthy expression or the last falsey expression (if all expressions are falsey):

1 // 0 falsey
2 // 'cucumber' truthy
3 // 42 truthy
4 > 0 || 'cucumber' || 42
5 // => 'cucumber'
6 > 0 || false || undefined
7 // => undefined

The AND operator will return the last truthy expression or the first falsey expression (if any falsey expression is encountered):

1 // 0 falsey
2 // 'cucumber' truthy
3 // 42 truthy
4 > 0 && 'cucumber' && 42
5 // => 0
6 > true && 'cucumber' && 42
7 // => 42

Exception Handling

Exception handling works similar as in C#, you have your familiar try/catch/finally blocks:

1 > try { asdf; } 
2   catch (e) { console.log(e.message);} 
3   finally { console.log('done!');}
4 // => asdf is not defined
5 // => done!

And you can throw new exceptions with the throw keyword:

1 > throw new Error("We're all gonna die!");
2 // => Uncaught Error: We're all gonna die!

Additionally, you can improve your error semantics and create custom errors by inheriting the Error prototype.

Regular Expressions

JavaScript also supports regular expressions. You can create a regular expression in two ways, either by wrapping the expression between slash (/):

1 > var matchNumbers = /\d+/;
2 > matchNumbers.test('40 gold coins');
3 // => true
4 > matchNumbers.exec('40 gold coints');
5 // => ["40"]

Or by creating a RegExp object:

1 > var matchItems = new RegExp('\\D+');
2 > matchItems.test('40 gold coins');
3 // => true
4 > matchItems.exec('40 gold coints');
5 // => [" gold coins"]

Strings have built-in support for regular expressions as well with the match and search methods:

1 > var bagOfGold = '30 gold coins';
2 > bagOfGold.match(/\d+/);
3 // => ['30']
4 > bagOfGold.search(/\d+/);
5 // => 0 (index where first match is found)

But Beware, JavaScript Can Be Weird and Dangerous

So far you’ve seen the bests parts of JavaScript and nothing too weird or inconsistent. But sometimes you’ll experience strange behaviors in some less visited corners of JavaScript like any of the following:

 1 > x = 10;
 2 // => added a variable to the global scope (window.x)
 3 > NaN == NaN
 4 // => false
 5 > null == undefined
 6 // => true
 7 > typeof(null)
 8 // => object
 9 > [] + []
10 // => ''
11 > [] + {}
12 // => {}
13 > {} + []
14 // => 0
15 > {} + {}
16 // => NaN

Oftentimes you won’t run into these issues when building real web applications and my advice is that you ignore them. Be aware that they exist but just don’t use them, or use patterns or conventions to avoid them.

Concluding

And that was a summary of pretty much the whole JavaScript language. I really hope it has sparkled your interest for JavaScript and that you cannot wait to turn the next page and learn more. But first, let’s make a quick review of what you’ve learned in this chapter.

We’ve seen that JavaScript is a very flexible dynamic language that supports many paradigms of programming and has a lot of great features.

You have learned the many things you can do with strings and ES6 string templates. How functions are very independent entities that can live their own lives completely separate from objects and how they are a fundamental building block of applications in JavaScript. You also discovered arrow functions that resemble lambdas in C# and let you write super terse and beautiful code.

We took a look at objects, object initializers, prototypical inheritance and ES6 classes. We saw the different data structures supported, the versatility of the array and an overview of the new ES6 Map and Set.

We also examined more general language features like the flow control structures and logical operators. We saw the difference between abstract comparison and strict comparison, highlighted the implicit type conversion inherent to JavaScript, the existence of the concepts of truthy and falsey and the way the OR and AND operators work.

Finally we reviewed exception handling and regular expressions, and we saw some of the weird and best-avoided behaviors in JavaScript.

The Basics Of JavaScript Functions

functions,
functions everywhere  

        - Buzz Lightyearvascript
        Explorer

The Basics Of Functions

Functions are the most fundamental building blocks of JavaScript applications. They are the safekeepers of the logic within our programs but also the primitives upon which we build programmatic constructs such as classes and modules.

JavaScript provides different ways to declare and use functions, each with their own nuances and limitations. So given the fact that they are such a fundamental part of the language it is important that you are aware of these characteristics when you are writing JavaScript.

Welcome to the first step in your journey to JavaScript mastery! Let’s get started!

Functions are the Key

Did you know that there are not one but two ways to write functions in JavaScript? Well, now you do. You can either write them as function expressions or function declarations. It will be very helpful for you to understand the difference and the implications of writing functions in either of these two styles because they work in a very different manner that will impact the readability of your code and how easy or hard it is to debug.

This is a function expression:

1 // anonymous function expression
2 var castFireballSpell = function(){
3   // chaos and mayhem
4 };

And this is a function declaration:

1 // function declaration
2 function castFireballSpell(){
3   // it's getting hot in here...
4 }

As you can appreciate, in their most common incarnations function expressions and function declarations look very similar. That’s why it is especially important to understand that they are actually very different and behave in disparate ways from each other.

Let’s examine each of them in greater detail.

Function Expressions

We use the function expression style whenever we declare a function like an expression, either by assigning it to a variable:

1 // an anonymous function expression
2 var castFireballSpell = function(){
3     console.log('...chaos and mayhem');
4 };
5 castFireballSpell();
6 // => ...chaos and mayhem

A property within an object:

1 // another anonymous function expression as a property of an object
2 var magician = {
3     castFireballSpell: function() {
4         console.log('muahaha! Eat this fireball!');
5     }
6 };
7 magician.castFireballSpell();
8 // => muahaha! Eat this fireball!

Or passing it as an argument to another function (like a lambda - note that I am using the term lambda in the sense of function as value):

 1 // yet another anonymous function expression passed as an argument
 2 var castCombo = function(spellOne, spellTwo){
 3     console.log('Combo Magic!!!!');
 4     spellOne();
 5     spellTwo();
 6 }
 7 
 8 castCombo(function(){
 9     console.log('FireBalllllzzz!!');
10 }, function(){
11     console.log('And Spectral Shield!!');
12 });
13 
14 // => Combo Magic!!!!
15 // => FireBalllllzzz!!
16 // => And Spectral Shield!!

There are a couple of important considerations you need to take into account when using function expressions like the ones above: they are all anonymous functions - they don’t have a name - and if stored within a variable they are subjected to the same hoisting rules that apply to any other variable in JavaScript. But what is hoisting? And how a function being anonymous can affect our programs?.

JavaScript Arcana: Function Scope and Hoisting

An interesting quirk about JavaScript is that, unlike many other languages, variables in JavaScript have function scope (as opposed to block scope). That is, it is the functions themselves that create scopes for variables and not the blocks. This can be better illustrated by an example:

 1 function openPandoraBox(){
 2 
 3     if (true){
 4         var treasure = 'mouse';
 5     }
 6     console.log('the pandora box holds a: **' + treasure + '**');
 7 }
 8 openPandoraBox();
 9 // => the pandora box holds a: **mouse**
10 // WAT!? x is declared inside an if block. 
11 // How can it be picked up by the console.log??
12 // one word: function-scope 

What happens in this piece of code above is that the JavaScript runtime hoists (moves up) all variables within a function definition to the beginning of the function body. And does it even with variables declared within blocks of code such as if statements. This means that the function that you see above is equivalent to this one:

1 function openPandoraBox(){
2     // The variable definition is hoisted up here
3     var treasure = undefined;
4     if (true){
5         treasure = 'mouse';
6     }
7     console.log('the pandora box holds a: **' + treasure + '**');
8     // => the pandora box holds a: **mouse**
9 }

Where the scope of the treasure variable isn’t only the if statement but the whole function. In yet another example of hoisting the variable i that we declare inside the for loop is actually part of the entire function (Shocker!!):

 1 function aMagicFunctionToIllustrateHoisting(){
 2     // in reality
 3     // var i = undefined
 4 
 5     console.log('before i =' + i);
 6     // => before i = undefined
 7 
 8     for(var i = 0; i < 10; i++){
 9         // jara jara
10     }
11 
12     console.log('after i = ' + i);
13     // => after i = 10
14 }

This is the reason why JavaScript developers - seasoned JavaScriptmancers - usually write all variable declarations at the beginning of a function. They do it in order to be more explicit about what is really happening when a function is evaluated and to avoid unnecessary bugs.

If you take a look at jQuery for instance, a popular JavaScript open source library, you’ll be able to appreciate this technique everywhere:

 1 /**
 2  * Load a url into a page
 3  */
 4 jQuery.fn.load = function( url, params, callback ) {
 5     var selector, type, response,
 6         self = this,
 7         off = url.indexOf(" ");
 8 
 9     //... more codes here
10 }

Functions being the stewards of scope of an application is pretty interesting because, all of the sudden, a function is not only used for encapsulating and abstracting a piece of logic but also for structural reasons. That is, a way to organize and distribute bits and pieces of functionality and code. For instance, you’ll often see functions being declared inside other functions:

 1 // declaring a function inside a function?
 2 // Ain't that weird????
 3 function blessMany(many){
 4   many.forEach(bless);
 5   
 6   function bless(target){
 7     console.log('You bless ' + target + '. (+5 WillPower) ');
 8   }
 9 }
10 
11 blessMany(['john snow', 'sansa stark']);
12 // => You bless John Snow (+5 Willpower) 
13 // => You bless Sansa Stark (+5 Willpower)

This probably looks very weird if you are coming from C#. But up until the recent advent of ES6 modules this was the only way we had to group pieces of loosely related functionality.

JavaScript Arcana Resolved: Variables with Block Scope With ES6 let and const

Happily for you and happily for me ES6 comes with not one, but two ways to declare variables with block scope: the new let and const keywords. From this point forward I invite you to start using let and achieve a more C#-like style of writing code where you declare variables closer to where you use them.

And so, if we rewrite the example we used to illustrate function scope with let, we’ll obtain a very different yet more familiar result:

 1 function openPandoraBoxWithBlockScope(){ // new scope for function b\
 2 lock
 3 
 4     if (true){ // new scope for if block
 5         let treasure = 'mouse';
 6     }
 7     console.log('the pandora box holds a: **' + treasure + '**');
 8 }
 9 openPandoraBoxWithBlockScope();
10 // ReferenceError: treasure is not defined
11 // fiuuuu now everything makes sense again

Now the treasure variable only exists within the if statement block.

Alternatively, you can use the const keyword to declare constant variables with block scope.

 1 function shallIPass(){ // new scope for youShallNotPass block
 2     let youShallPass = 'you Shall Pass!', 
 3         youShallNotPass = 'You Shall Not Pass!';
 4     // console.log(canIPass); // => ReferenceError
 5 
 6     if (true){ // new scope for if block
 7         const canIPass = youShallNotPass;
 8         console.log(canIPass); // => 'You Shall Not Pass!'
 9         canIPass = youShallPass; 
10         // => TypeError: Assignment to a constant variable
11     }
12 
13     console.log(canIPass); // => undefined
14     // ReferenceError: x is not defined
15 }
16 shallIPass();
17 // => you Shall not Pass!
18 // => TypeError: Assignment to a constant variable

Variables declared with the const keyword behave in a very similar way to C#. Attempting to make the constant refer to a different value will cause an exception.

However, it is important to understand that if the constant refers to an object, you can still modify its properties:

1 const fourHorsemen = ['conquest', 'war', 'famine', 'death'];
2 fourHorsemen.push('jaime');
3 console.log(`${fourHorsemen} waaat`);
4 // => ['conquest', 'wat', 'famine', 'death', 'jaime'] waaat

This means that const only affects the act of binding a value to a variable, and not the act of modifying that value itself. In order to make an object immutable you need to use Object.freeze but that’s knowledge best kept for another chapter about the beauty of objects. We’ll stick to functions for a little bit longer.

Another aspect of let and const that is interesting is that they do not hoist variables to the top of a block. Instead, if you attempt to use a variable before it has been defined you’ll get an exception (cheers for some sane behavior):

 1 function openPandoraBoxWithBlockScopeAndHoisting(){ 
 2     // new scope for function block
 3 
 4     if (true){ 
 5         // new scope for if block
 6         console.log('the pandora box holds a: **' + treasure + '**');
 7         // => ReferenceError: treasure is not defined;
 8         let treasure = 'mouse';
 9     }
10 }
11 openPandoraBoxWithBlockScopeAndHoisting();
12 // => ReferenceError: treasure is not defined;

Now that you’ve learnt some of the main characteristics of function expressions let’s take a look at the two types of function expressions that are available to you in JavaScript: anonymous function expressions and named function expressions.

Anonymous Function Expressions

Anonymous function expressions are particularly interesting because even though you read the following:

1 var castFireballSpell = function(){
2     console.log('...chaos and mayhem');
3 };

And you may be tempted to think that the name of the function is castFireballSpell, it is not!?! castFireballSpell is just a variable we use to store an anonymous function. You can appreciate this anonymity by inspecting the name property of the function itself:

1 var castFireballSpell = function(){
2     console.log('...chaos and mayhem');
3 };
4 console.log(castFireballSpell.name);
5 // => ""
6 // no name!

Luckily for us, as long as an anonymous function is bound to a variable, the developer tools in modern browsers will use that variable when displaying errors in call stacks (which is a savior when debugging):

 1 // inspecting a call stack for an anonymous function bound 
 2 // to a variable
 3 var castFireballSpellWithError = function(){
 4     console.log('...chaos and mayhem');
 5     try {
 6         throw new Error();
 7     } catch (e) {
 8         console.log('stack: ', e.stack);
 9     }
10 };
11 castFireballSpellWithError();
12 //=> stack:  Error
13 // at castFireballSpellWithError (somefile:53:15)
14 // at window.onload (somefile:58:1)

Even if we use this function as a argument:

1 // If you use this function as a lambda the name is 
2 // still shown in the call stack:
3 var spellLauncher = function(f){ f(); }
4 spellLauncher(castFireballSpellWithError);
5 // => stack:  Error
6 // at castFireballSpellWithError (somefile:56:15)
7 // at spellLauncher (somefile:68:35)
8 // at window.onload (somefile:69:1)

However, an unbound anonymous function will show as completely anonymous within the call stack making it harder to debug when errors occur (I will refer to these functions as strict anonymous function from now on):

 1 // strict anonymous function don't appear in the call stack
 2 spellLauncher(function(){
 3     console.log('...chaos and mayhem');
 4     try {
 5         throw new Error();
 6     } catch (e) {
 7         console.log('stack: ', e.stack);
 8     }
 9 });
10 //=> stack:  Error
11 // at somefile:76:15
12 // at spellLauncher (somefile:68:35)
13 // at window.onload (somefile:73:1)

This lack of name will also affect the ability to use recursion because a function that doesn’t have a name cannot call itself from inside its body. In spite of that and just like in the previous examples, if we have the anonymous function bound to a variable we take a free pass and can take advantage of JavaScript lexical scope to access the function through that variable:

 1 // you can use recursion when an anonymous function is bound to a va\
 2 riable
 3 var castManyFireballsSpell = function(n){
 4     // this function encloses the castManyFireballsSpell variable
 5     // and thus becomes a closure
 6     console.log('... SHOOOOOOOOOSH ....');
 7     if (n > 0)
 8         castManyFireballsSpell(n-1);
 9 };
10 castManyFireballsSpell(3);
11 // => ... SHOOOOOOOOOSH ....
12 //    ... SHOOOOOOOOOSH ....
13 //    ... SHOOOOOOOOOSH ....
14 //    ... SHOOOOOOOOOSH ....

Notice that this is a pretty brittle way of using recursion. In this example we are using the variable castManyFireballsSpell to access the anonymous function from within itself. If, at some later point in time, you happen to set the variable to another function you’ll get into a pickle. A tricky situation with a very subtle bug where the original function will call this new function instead of itself (so no more recursion and weird unexpected stuff happening).

A strict anonymous function, on the other hand, has no way to refer to itself and thus you lose the ability to use recursion. For instance, this is the case when we define an anonymous function expression and we invoke it right away:

1 // but there's no way for an anonymous function 
2 // to call itself in any other way
3 (function(n){
4     console.log('... SHOOOOOOOOOSH ....');
5     if (n > 0) {
6         // I cannot call myself... :(
7     }
8 }(5));
9 // => ... SHOOOOOOOOOSH ....

In summary, the fact that common function expressions are anonymous makes them harder to debug and complicates the use of recursion. And the fact that they are hoisted as variables, a trait common to all function expressions, also makes them less readable as we’ll see in a bit with a larger example program.

Let’s see some ways to ameliorate or lessen these issues.

Named Function expressions

You can solve the problem of anonymity that we’ve seen thus far by using named function expressions. You can declare named function expressions by adding a name after the function keyword:

1 // named function expression
2 var castFireballSpell = function castFireballSpell(){
3   // mayhem and chaos
4 };
5 console.log("this function's name is: ", castFireballSpell.name);
6 // => this function's name is castFireballSpell

The example above shows a variable and a function expression both named castFireballSpell. A named function expression always appears correctly represented in the call stacks even when used as an argument (and not bound to a variable):

 1 // A named function expression always appears in the call stack
 2 spellLauncher(function spreadChaosAndMayhem(){
 3   console.log('...chaos and mayhem');
 4   try {
 5     throw new Error();
 6   } catch (e) {
 7     console.log('stack: ', e.stack);
 8   }
 9 });
10 // stack:  Error
11 // at spreadChaosAndMayhem (somefile:134:15)
12 // at spellLauncher (somefile:68:35)
13 // at window.onload (somefile:131:1)

This helps while debugging and makes your code more readable since you can read the name of the function and understand what it’s meant to do without looking at its implementation.

An interesting fact about named function expressions is that you cannot call them by their name from the outside:

1 var castFireballSpell = function cucumber(){
2     // cucumber?
3 };
4 cucumber();
5 // => ReferenceError: cucumber is not defined

The name of a function expression is more of an internal identifier that can be used from inside the function body. This is very useful when working with recursion. For instance, if we declare a recursive named function expression and invoke it right away it just works:

 1 // but you can call it from the function body 
 2 // which is helpful for recursion
 3 (function fireballSpellWithRecursion(n){
 4   console.log('... SHOOOOOOOOOSH ....');
 5   if (n > 0) {
 6     fireballSpellWithRecursion(n-1);
 7   }
 8 }(5));
 9 // => ... SHOOOOOOOOOSH ....
10 //    ... SHOOOOOOOOOSH ....
11 //    ... SHOOOOOOOOOSH ....
12 //    ... SHOOOOOOOOOSH ..... etc..

In summary, named function expressions improve on anonymous function expressions by increasing readability, improving the debugging process and allowing for a function to call itself.

Function Expressions are Hoisted as Variables

Function expressions are still problematic because they are hoisted like variables. But what does this mean exactly? It means that you can only use a function expression after you have declared it and therefore it forces you to write your code starting from the implementation details and continuing into higher levels of abstraction.

This is the opposite of what you want. Think about it. When you write a class as a C# developer, you start with the public API at the top of the class definition. Then you write the implementation of each method from top to bottom, from higher to lower levels of abstraction so that reading becomes natural. You open a file at the top, understand what it does at a glance by reading the intentional names that compose its public API and then you traverse the file down looking at the implementation details only when you need or want to.

Being forced to start from the opposite direction will have a negative impact in the readability of your code:

 1 (function (magic){
 2   // this function represents a module 'magic'
 3   // it's just a way to group like-minded pieces of code
 4 
 5   var oven = {
 6     open: function(){},
 7     placeBaking: function(){},
 8     increaseTemperature: function(){},
 9     claimVictory: function(){ return 'awesome cake';}
10   };
11 
12   var mix = function mix(ingredients){
13     console.log('mixin ingredients:', ingredients.join(''));
14     return 'un-appetizing mixture';
15   }
16 
17   var work = function work(mixture){
18     console.log('working ' + mixture);
19     return 'yet more un-appetizing dough';
20   };
21 
22   var bake = function bake(dough){
23     oven.open();
24     oven.placeBaking(dough);
25     oven.increaseTemperature(200);
26     // insta-oven!
27     return oven.claimVictory();
28   };
29 
30   var enchant = function enchant(ingredients){
31     var mixture = mix(ingredients),
32       dough = work(mixture),
33       cake = bake(dough);
34     return cake;
35   };
36 
37   // This is the public API of this module
38   // and it's almost hidden down here
39   magic.enchant = enchant;
40 
41 }(window.magic || (window.magic = {})));
42 
43 var cake = magic.enchant(['flour', 'mandragora', 'dragon', 'chicken \
44 foot']);
45 // => mixin ingredients:  flour mandragora dragon chicken foot
46 // => working un-appetizing mixture
47 console.log(cake);
48 // => awesome cake

If you try to reorder the different functions within the module so that they start from the public API and continue from top to bottom, from higher to lower levels of abstraction you’ll encounter many issues:

 1 (function (magic){
 2   // this function represents a module 'magic'
 3   // it's just a way to group like-minded pieces of code
 4 
 5   // exposing enchant as the API for the 'magic' module
 6   magic.enchant = enchant;
 7   // => hoisting issue, enchant is undefined at this point
 8   // so we are just exposing an undefined variable thinking it is a \
 9 function
10 
11   // if uncommented this would cause an exception
12   // enchant();
13   // => TypeError: enchant is not a function
14   // => hoisting issue, enchant is undefined at this point
15 
16   var enchant = function enchant(ingredients){
17     var mixture = mix(ingredients),
18       dough = work(mixture),
19       cake = bake(dough);
20     return cake;
21   };
22 
23   // if uncommented this would cause an exception
24   // enchant();
25   // => TypeError: mix is not a function (it's undefined at this poi\
26 nt)
27   // hoisting issue, mix is undefined at this point
28 
29   /* rest of the code...
30   var mix = function mix(ingredients){}
31   var work = function work(mixture){};
32   var bake = function bake(dough){};
33   var oven = {};
34   */
35 
36 }(window.magic || (window.magic = {})));
37 
38 try {
39   var cake = magic.enchant(['flour', 'mandragora', 'dragon', 'chicke\
40 n foot']);
41   console.log(cake);
42 } catch (e) {
43   console.warn('ups!!!!!!', e);
44   // => ups!!!!!! TypeError: magic.enchant is not a function
45 }

In this example we use function expressions to define every function. Because they are hoisted like variables when we try to assign the enchant function to our magic.enchant object its value is undefined. This results in us exposing an undefined value to the outside world instead of a helpful function to enchant delicious cakes. In a similar way, when we attempt to call the enchant function before either enchant or mix have been initialized we get a TypeError exception.

In summary, both named and anonymous function expressions are hoisted as variables. This affects their readability and can cause bugs when we try to run a function or expose it as part of the public API of a module before it has been defined. Although you could use let and const to prevent hoisting, there’s a better way you can declare your functions: Function declarations.

Function Declarations

Function declarations have some advantages over function expressions:

• They are named, and you can use that name from outside and from within the function.
• They are not hoisted as variables but as a whole, which makes them impervious to hoisting problems.

This is how you write a function declaration:

1 // function declaration
2 function castFireballSpell(){
3   // it's getting hot in here...
4 }

As you learned just a moment ago, function declarations are hoisted in a very special way. When the JavaScript runtime processes this piece of code:

 1 var message = "hello";
 2 
 3 // some more code here...
 4 
 5 // function expression
 6 var sayHi = function(){console.log('hi!')}; 
 7 
 8 // some more code here...
 9 
10 // function declaration
11 function sayHello(){ 
12   console.log(msg);
13 }

It’s going to rearrange it by hoisting the whole sayHello function and only the declaration of the variables message and sayHi:

 1 // hoisted as variables
 2 var message, sayHi;
 3 
 4 // hoisted as a whole
 5 function sayHello(){
 6 console.log(msg);
 7 }
 8 
 9 message = "hello";
10 // some more code here...
11 sayHi = function(){console.log('hi!')};
12 // some more code here...

Because of this special hoisting behavior, function declarations will enable you to write your JavaScript modules from higher to lower levels of abstraction just like we discussed earlier and as you can see in this example below:

 1 // with function declarations you can write functions like this
 2 // and don't worry about hoisting issues at all
 3 (function(magic){
 4 
 5   // public API of the magic module
 6   magic.enchant = enchant;
 7 
 8   // functions from higher to lower level of abstraction
 9   function enchant(ingredients){
10     var mixture = mix(ingredients),
11       dough = work(mixture),
12       cake = bake(dough);
13     return cake;
14   }
15 
16   // these are private functions to this module
17   function mix(ingredients){
18     console.log('mixin ingredients:', ingredients.join(''));
19     return 'un-appetizing mixture';
20   }
21 
22   function work(mixture){
23     console.log('working ' + mixture);
24     return 'yet more un-appetizing dough';
25   }
26 
27   function bake(dough){
28     oven.open();
29     oven.placeBaking(dough);
30     oven.increaseTemperature(200);
31     // insta-oven!
32     return oven.claimVictory();
33   }
34 
35   var oven = {
36     open: function(){},
37     placeBaking: function(){},
38     increaseTemperature: function(){},
39     claimVictory: function(){ return 'awesome cake';}
40   };
41 
42 }(window.magic || (window.magic = {})));
43 
44 var cake = magic.enchant(['flour', 'mandragora', 'dragon', 'chicken \
45 foot']);
46 // => mixin ingredients:  flour mandragora dragon chicken foot
47 // => working un-appetizing mixture
48 console.log(cake);
49 // => awesome cake

And, just like function expressions, you can also use function declarations as values (and arguments). Notice the disintegrate function below:

 1 var orc = {toString: function(){return 'a mighty evil orc';}};
 2 var warg = {toString: function(){return 'a terrible warg';}};
 3 var things = [1, orc, warg, false];
 4 
 5 // using the disintegrate function declaration as an argument
 6 // nice and readable
 7 things.forEach(disintegrate);
 8 
 9 function disintegrate(thing){
10   console.log(thing + ' suddenly disappears into nothingness...');
11 }
12 
13 // => 1 suddenly disappears into nothingness...
14 // a mighty evil orc suddenly disappears into nothingness...
15 // a terrible warg suddenly disappears into nothingness...
16 // false suddenly disappears into nothingness...

There’s something interesting happening in this example above that is worthy of note: type coercion. When the body of the disintegrate function is evaluated, the expression below:

1 thing + ' suddenly disappears into nothingness...'

Coerces the thing variable to a string type. In the case of the orc and warg which are objects that means calling the toString method and obtaining a string representation of either of these objects.

Concluding: Prefer Function Declarations and Named Function Expressions

Function expressions have some limitations:

1. They are anonymous, which can make them less readable, harder to debug and use in recursion
2. They are hoisted as variables which can lead to bugs and forces you to declare them before you can use them

Named function expressions solve the problem of anonymity. They make your vanilla function expressions more readable, easier to debug and enable recursion.

Function declarations solve both problems of anonymity and hoisting (they are hoisted as a whole), and even allow you to write code from higher to lower levels of abstraction.

You can use the let and const keywords to solve the problems with hoisting related to function expressions but you don’t get the nice top to bottom narrative that you get with function declarations. That is, with let and const you cannot use a function before you have declared it, if you attempt to do so you’ll get an exception.

In summary, and based on the characteristics of functions in JavaScript, prefer named function expressions and function declarations over anonymous function expressions.

Hope you have enjoyed this chapter about the different ways you can write functions in JavaScript. Up next, We will discuss the most common patterns to achieve default values, multiple arguments and function overloading when writing functions in JavaScript and we’ll see how some of the new features in ES6 provide native support for some of these.

Exercises

Useful Function Patterns: Default Arguments

Put yourself in the place of the listener,
of the eater,
of the reader,
of the user of your carefully crafted spells.

Think from the outside in, 
and you'll be rewarded manyfold.

Think developer experience!!
  
        - Llroc
        Warrior Poet

Have You Heard Of Defaults?

I don’t know you but I’m always trying to write less code and build beautiful APIs for myself and other developers. One small way to achieve that is by using default arguments. Defaults let you add more intention behind your APIs and provide a shortcut to the most common functionality or task carried out by a function.

In this and the next few chapters we’ll discuss several patterns that you can use to improve the usability of the functions you write in JavaScript: defaults, multiple arguments and function overloading. Let’s get started with defaults in ES5 and ES6.

Using Default Arguments in JavaScript Today

If you have had the chance to take a look at some Javascript code, you may have encountered the following statement and wondered what (the heck) it meant:

1 var type = type || "GET";

Hold on tight because we are about to unveil the mystery. That statement right there has been the prevalent approach to writing defaults in JavaScript for ages. If you do a little of a mental exercise and try to remember what you read about the || (OR) operator in the introduction you’ll recall that this operator behaves in quite a special way: It returns the first truthy expression of those being evaluated or the last expression if none is truthy. As usual, this behavior is better illustrated through an example:

 1 > false || 42 || false
 2 // => 42
 3 
 4 > "" || false
 5 // => false
 6 
 7 > "" || {}
 8 // => Object {}
 9 
10 > var numberOfPotatos = undefined
11 > numberOfPotatos || 3
12 // => 3
13 
14 > numberOfPotatos = 5
15 > numberOfPotatos || 3
16 // => 5

Since up until ES6 there was no native support for defaults and using the || operator was the most compact way to achieve it, this pattern soon became the de facto standard for defaults throughout the community and is often used in JavaScript applications. You just need to take a sneak peak in any popular open source library to find it used in innumerable situations:

1 // from jquery loads.js 
2 // (https://github.com/jquery/jquery/blob/master/src/ajax/load.js)
3 type: type || "GET",
4 
5 // or from yeoman router.js 
6 // (https://github.com/yeoman/yo/blob/master/lib/router.js)
7 this.conf = conf || new Configstore(pkg.name, {
8     generatorRunCount: {}
9   });

One of the most common use of defaults happens when evaluating the arguments of a function like in this castIceCone spell:

 1 function castIceCone(mana, options){
 2   // we take advantage of the || operator to define defaults
 3   var mana = mana || 5,
 4     options = options || {direction: 'forward', damageX: 10},
 5     direction = options.direction || 'forward',
 6     damageX = options.damage || 10,
 7     damage = 2*mana + damageX;
 8     
 9   console.log("You spend " + mana + 
10               " mana and cast a frozen ice cone " + direction + 
11               " (" + damage + " DMG).");
12 }

The castIceCone function has two arguments: a mana argument that represents the amount of mana a powerful wizard is going to spend in casting the ice cone and an additional options object with finer details.

The function makes extensive use of the || operator to provide defaults for all possible cases. In the simplest and most convenient of scenarios the user of this function would just call it directly, and when more finesse is needed she or he could populate the richer options argument:

 1 castIceCone();
 2 // => You spend 5 mana and cast a frozen ice cone forward (20 DMG)
 3 castIceCone(10);
 4 // => You spend 5 mana and cast a frozen ice cone forward (20 DMG)
 5 castIceCone(10, { damage: 200});
 6 // => You spend 5 mana and cast a frozen ice cone forward (220 DMG)
 7 castIceCone(10, { direction: 'to Mordor'})
 8 // => You spend 10 mana and cast a frozen ice cone to Mordor (30 DMG)
 9 castIceCone(10, { direction: 'to Mordor', damage: 200})
10 // => You spend 10 mana and cast a frozen ice cone to Mordor (220 DM\
11 G)

An alternative way to do defaults is to wrap them within an object.

Defaults with Objects

In addition to relying on the || operator, you can use an object to gather your default values. Whenever the function is called you merge the arguments provided by the user with the object that represents the defaults. The default values will only be applied when the actual arguments are missing.

You can define a mergeDefaults function to perform the merge operation:

1 function mergeDefaults(args, defaults){
2   if (!args) args = {};
3   for (var prop in defaults) {
4     if (defaults.hasOwnProperty(prop) && !args[prop]) {
5       args[prop] = defaults[prop];
6     }
7   }
8   return args;
9 }

And then apply it to the arguments passed to the function like in this castLightningBolt spell:

 1 function castLightningBolt(details){
 2   // we define the defaults as an object
 3   var defaults = {
 4   	mana: 5,
 5     direction: 'forward'
 6   };
 7   // merge details and defaults
 8   // properties are overwritten from right to left
 9   details = mergeDefaults(details, defaults);
10   
11   console.log('You spend ' + details.mana + 
12       ' and cast a powerful lightning bolt ' + 
13       details.direction + '!!!');
14 }

Which provides a similar defaults developer experience to that of the first example:

1 castLightningBolt();
2 // => You spend 5 and cast a powerful lightning bolt forward!!!
3 castLightningBolt({mana: 100});
4 // => You spend 100 and cast a powerful lightning bolt forward!!!
5 castLightningBolt({direction: 'to the right'});
6 // => You spend 5 and cast a powerful lightning bolt to the right!!!
7 castLightningBolt({mana: 10, direction: 'to Mordor'});
8 // => You spend 10 and cast a powerful lightning bolt to Mordor!!!

More often though you will probably rely on a popular open source library. Libraries like jQuery, underscore or lodash usually come with a lot of utility functions that you can use for this and many other purposes. For instance, jQuery comes with the $.extend function and underscore comes with both the _.defaults and _.extend functions that could help you in this scenario.

Let’s update the previous example with code from these two libraries:

 1 function castLightningBoltOSS(details){
 2   // we define the defaults as an object
 3   var defaults = {
 4   	  mana: 5,
 5       direction: 'in front of you'
 6   };
 7   // extend details with defaults
 8   // properties are overwritten from right to left
 9   // jQuery:
10   details = $.extend({}, defaults, details);
11   // underscore:
12   //details = _.extend({}, defaults, details);
13   
14   // to use defaults switch argument places
15   // properties are only overwritten if they are undefined
16   // underscore:
17   //details = _.defaults({},details, defaults);
18   
19   console.log('You spend ' + details.mana + 
20       ' and cast a powerful lightning bolt ' + 
21       details.direction + '!!!');
22 }

If you have kept an eye on ES6 you may know that it comes with a native version of the jQuery $.extend method called Object.assign. Indeed, you can update the previous example as follows and achieve the same result:

1 //details = $.extend({}, defaults, details);
2 details = Object.assign({}, defaults, details);

However, if you are planning to use ES6, there’s an even better way to use defaults.

Native Default Arguments with ECMAScript 6

ES6 makes it dead easy to declare default arguments. Just like in C# you use the equal sign "=" and assign a default value beside the argument itself:

1 function castIceCone(mana=5){
2   console.log(`You spend ${mana} mana and casts a terrible ice cone`\
3 );
4 }
5 
6 castIceCone();
7 // => You spend 5 mana and casts a terrible ice cone
8 castIceCone(10);
9 // => You spend 10 mana and casts a terrible ice cone

JavaScript takes defaults even further because they are not limited to constant expressions like C# optional arguments. In JavaScript, any expression is a valid default argument.

For instance, you can use entire objects as defaults:

 1 function castIceCone(mana=5, options={direction:'forward'}){
 2   console.log(`You spend ${mana} mana and casts a ` + 
 3     `terrible ice cone ${options.direction}`);
 4 }
 5 
 6 castIceCone();
 7 // => You spend 5 mana and casts a terrible ice cone forward
 8 castIceCone(10);    
 9 // => You spend 10 mana and casts a terrible ice cone forward
10 castIceCone(10, {direction: 'to Mordor'});
11 // => You spend 10 mana and casts a terrible ice cone to Mordor
12 castIceCone(10, {duck: 'cuack'});
13 // => You spend 10 mana and casts a terrible ice cone undefined

If you take a closer look at the end of the example above, you’ll realize that we have a small bug in our function. We are setting a default for the entire options object but not for parts of it. So if the developer provides an object with the direction property missing, we will get a strange result (writing undefined to the console).

We can solve this problem by taking advantage of the new destructuring syntax which allows you to assign argument properties directly to variables within a function, and at the same time provide defaults to parts of an object:

 1 function castIceConeWithDestructuring(mana=5, 
 2           {direction='forward'}={direction:'forward'}){
 3 
 4   console.log(`You spend ${mana} mana and casts a ` + 
 5     `terrible ice cone ${direction}`);
 6 }
 7 castIceConeWithDestructuring();
 8 // => You spend 5 mana and casts a terrible ice cone forward
 9 castIceCone(10, {direction: 'to Mordor'});
10 // => You spend 10 mana and casts a terrible ice cone to Mordor
11 castIceConeWithDestructuring(10, {duck: 'cuack'});
12 // => You spend 10 mana and casts a terrible ice cone forward

In this example we use argument destructuring {direction='forward'} to:

• Extract the property direction from the argument provided to the function at once. This allows us to write direction instead of the more verbose options.direction that we used in previous examples.
• Provide a default value for the direction property in the case that the function is called with a options object that misses that property. It therefore solves the problem with the {duck: 'cuack'} example.

Finally, taking the freedom of defaults to the extreme, you are not limited to arbitrary objects either, you can even use a function expression as a default (I expect your mind has just been blown by this, this… very… second):

 1 function castSpell(spell=function(){console.log('holy shit a callbac\
 2 k!');}){
 3   spell();
 4 }
 5 
 6 castSpell();
 7 // => holy s* a callback!
 8 castSpell(function(){
 9   console.log("balefire!!!! You've been wiped out of existence");
10 });
11 // => balefire!!!! You've been wiped out of existence

Concluding

Yey! In this chapter you’ve learned several ways in which you can use defaults in JavaScript whether you are using ES5 or ES6 and beyond. Taking advantage of defaults will let you write less code and provide a slightly better user experience to the consumers of the functions that you write.

Up next, more function patterns with multiple arguments and the rest operator!

Exercises

More Useful Function Patterns: Arbitrary Arguments

What works for one,
may work for many...
  
        - Eccason,
        Maester of the Aethis

An Arbitrary Number of Arguments

Sometimes you write a function that performs some sort of action based on a single argument. Some time later you realize that it would be nice if you could use that same function, but this time, with an arbitrary number of arguments. You may be tempted to change the interface of the original function to take an array instead of a single item. In doing so, however, you break the code that is using the function and force any future developers to wrap the arguments being sent inside an array, even when there’s only a single argument.

In this specific scenario, you may want to do something different. You may want to keep the function interface as it is and elegantly extend it to support multiple arguments without affecting any existing code. That’s what we do in C# with the params keyword, and what you can achieve in JavaScript via the arguments object or ES6 rest parameter syntax.

This is what you’ll learn in this chapter. But first, did you know that JavaScript functions are pretty peculiar about their arguments?

The Craziness Of Function Arguments in JavaScript

JavaScript gives you a lot of freedom when it comes to handling function parameters and arguments. For instance, you can declare a function with a specific number of parameters and, if you wish, call it without any arguments at all.

Imagine a function heal that casts a healing spell on a person:

1 function heal(person, inchantation, modifier){
2   var healedHp;
3   modifier = modifier || 1;
4   healedHp = modifier * 100;
5 
6   console.log('you heal ' + person + ' with ' + inchantation + 
7               ' spell (+' + healedHp + 'hp)' );
8   person.hp += healedHp;
9 }

This function has an arity of 3, that is, it expects 3 arguments. You can verify this accessing its length property. (A popular interview question by the way):

1 console.log(heal.length);
2 // => 3

Thanks to the magic of JavaScript’s infinite freedom you can call it without any arguments at all. Although this doesn’t mean that it will work:

1 try {
2   heal();
3 } catch (e) {
4   console.log(e)
5 }
6 // => you heal undefined with undefined spell (+100hp)
7 // => TypeError: cannot read property hp of undefined

You can also call it with as many of those 3 arguments as you want:

 1 var JonSnow = {name: 'Jon Snow', hp: 5, 
 2                toString: function(){return this.name;}};
 3 
 4 heal(JonSnow);
 5 // => you heal Jon Snow with undefined spell (+100hp)
 6 
 7 heal(JonSnow, 'cure');
 8 // => you heal Jon Snow with cure spell (+100hp)
 9 
10 heal(JonSnow, 'super heal', /* modifier */ 2);
11 // => you heal Jon Snow with super heal spell (+200hp)

Or even with more arguments than the parameters defined in the function itself:

1 heal(JonSnow, 'heal', 1, 3, 2, 3, 'cucumber', 
2      {a: 1, b:2}, 'many arguments');
3 // => you heal Jon Snow with heal spell (+100hp)

It is up to you to implement the body of a function and handle each case as you see fit. But what happens when you want to write a function that takes an arbitrary number of arguments?

Functions with Arbitrary Arguments Right Now!

In C#, whenever we want to write such a function we use the params keyword. In JavaScript (up to ES5), on the other hand, there’s no keyword nor operator that allows us to do that.

The only possible approach is to use the arguments object. arguments, like this, is a special kind of object present within every function in JavaScript. Its whole purpose is to give access to the arguments used to call a function from inside the function itself.

Think about an obliterate spell that you could use to completely wipe out an enemy:

1 function obliterate(enemy){
2   console.log(enemy + " wiped out of the face of the earth");
3 }
4 
5 obliterate('batman');
6 // => batman wiped out of the face of the earth

But why stop at one? With arguments you can make an obliterate spell to wipe out all your enemies at once!

 1 function obliterate(){
 2   // Unfortunately arguments is not an array :O
 3   // so we need to convert it ourselves
 4   var victims = Array.prototype.slice.call(arguments, /* start */ 0);
 5 
 6   victims.forEach(function(victim){
 7     console.log(victim + " wiped off of the face of the earth");
 8   });
 9   console.log('*Everything* has been obliterated, ' + 
10               'oh great master of evil and deceit!');
11 }

Indeed, we can use our obliterate function with one or as many arguments as we want. We have extended our function API without breaking it:

 1 obliterate('batman');
 2 // => batman wiped out of the face of the earth
 3 // *Everything* has been obliterated, oh great master 
 4 // of evil and deceit!
 5 
 6 obliterate("John Doe", getPuppy(), 1, new Minion('Willy', 'troll'));
 7 /*
 8 John Doe wiped off of the face of the earth
 9 cute puppy wiped off of the face of the earth
10 1 wiped off of the face of the earth
11 Willy the troll wiped off of the face of the earth
12 *Everything* has been obliterated, oh great master 
13 of evil and deceit!
14 */
15 
16 function getPuppy(){
17   return {
18     cuteWoof: function(){console.log('wiii');},
19     toString: function(){return 'cute puppy';}
20   };
21 };
22 
23 function Minion(name, type){
24   this.name = name;
25   this.type = type;
26   this.toString = function(){ return name + " the " + type;};
27 }

As it goes, there are a couple of interesting things to point out in this example.

The first one is the fact that we are sending arguments of different types to the function and they are all treated seamlessly. That’s an example of duck typing in action where an object is defined by what it can do and not by its type. As long as the values that we pass as arguments support the interface the function expects - in this case the toString method - everything will work just fine.

The second thing to point out is the use of the Array.prototype.slice function. We use it to convert the arguments variable into a real array victims. While you would expect the arguments variable to be an array, it is not, it is an array-like object (and this, my friend, is another of JavaScript quirks right here).

Array-Like Objects

Here are the things you can do with an array-like object:

 1 function inspectArguments(){
 2 
 3   // you can index it:
 4   console.log("the first argument is ", arguments[0]);
 5   console.log("the second argument is ", arguments[1]);
 6 
 7   // you an enumerate it:
 8   // as in the arguments are enumerable like
 9   // any common array or object, and thus you can use
10   // the for/in loop
11   for (var idx in arguments) {
12     console.log("item at position " + idx + 
13                 " is " + arguments[idx]);
14   }
15 
16   // it has a length property
17   console.log("there are " + arguments.length + " arguments");
18 }
19 
20 inspectArguments("cucumber", "dried meat", "dagger", "rock");
21 // => the first argument is cucumber
22 // => the second argument is dried meat
23 // => item at position 1 is cucumber
24 // => etc...
25 // => there are 4 arguments

Because it is not an array it does not have any of the array functions that you would expect:

 1 function inspectArgumentsFunctions(){
 2   console.log("arguments.foreach is ", arguments.foreach);
 3   console.log("arguments.map is ", arguments.map);
 4   console.log("arguments.some is", arguments.some);
 5 }
 6 
 7 inspectArgumentsFunctions();
 8 // => arguments.foreach is undefined
 9 // => arguments.map is undefined
10 // => arguments.some is undefined

Using the slice function of Array.prototype allows you to convert arguments to an array and take advantage of all the nice array functions. This is what we did with the obliterate function:

1 function obliterate(){
2   //...
3   var victims = Array.prototype.slice.call(arguments, /* start */ 0);
4   victims.forEach(function(victim){
5       console.log(victim + " wiped out of the face of the earth");
6   });
7   //...
8 }

Alternatively, you can use the ES6 Array.from method for a more natural conversion of an array-like object into an array:

1 function obliterate(){
2   //...
3   var victims = Array.from(arguments);
4   victims.forEach(function(victim){
5       console.log(victim + " wiped out of the face of the earth");
6   });
7   //...
8 }

In the specific case of the arguments object ES6 rest syntax offers a much better alternative⁹ as you’ll find out soon.

Native Arbitrary Arguments with ES6 Rest Parameters

ES6 comes with a native way to handle arbitrary arguments: rest parameters.

All the complexity of using the arguments object in the previous examples can be substitued by rest parameters and handled seamlessly:

1 function obliterate(...victims){
2   victims.forEach(function(victim){
3     console.log(victim + " wiped out of the face of the earth");
4   });
5   console.log('*Everything* has been obliterated, ' + 
6               'oh great master of evil and deceit!');
7 }

When using rest parameters, victims becomes an array automatically so there’s no need to perform additional conversions. Indeed, if we use the new obliterate function as we did before it works perfectly:

 1 obliterate('batman');
 2 // => batman wiped out of the face of the earth
 3 // *Everything* has been obliterated, oh great master 
 4 // of evil and deceit!
 5 
 6 obliterate("John Doe", getPuppy(), 1, new Minion('Willy', 'troll'));
 7 /*
 8 John Doe wiped off of the face of the earth
 9 cute puppy wiped off of the face of the earth
10 1 wiped off of the face of the earth
11 Willy the troll wiped off of the face of the earth
12 *Everything* has been obliterated, oh great master of evil and decei\
13 t!
14 */

Rest paratemers can also be used in combination with normal parameters. For instance, imagine that the obliterate spell had an extra effect on the first enemy it encountered. We could rewrite it like this:

 1 function obliterate(unfortunateVictim, ...victims){
 2   console.log(unfortunateVictim + 
 3              " wiped out of the face of EXISTENCE " +
 4              "as if it had never existed.... Woooo");
 5   victims.forEach(function(victim){
 6     console.log(victim + " wiped out of the face of the earth");
 7   });
 8   console.log('*Everything* has been obliterated, ' + 
 9               'oh great master of evil and deceit!');
10 }

Upon using this malignant spell the first enemy would be removed from existence completely and utterly:

1 obliterate("John Doe", getPuppy(), 1, new Minion('Willy', 'troll'));
2 /*
3 John Doe wiped out of the face of EXISTENCE as if it had 
4 never existed.... Woooo
5 cute puppy wiped off of the face of the earth
6 etc...
7 */

Note how easily the rest parameters capture all the remaining arguments after unfortunateVictim. Beautiful!

You now know different ways to implement a function that takes an arbitrary number of arguments. A function that provides the same API regardless of being called with one or many arguments. But what if you just happen to have an array? What happens if the output of another function is an array of enemies that need to be obliterated? Well, that’s when the ES6 spread operator comes in handy.

The ES6 spread operator, among other things that you’ll learn later in this book, lets you seamlessly call these type of functions using an array as argument:

 1 let mortalEnemies = ["John Doe", getPuppy(), 1, 
 2                      new Minion('Willy', 'troll')];
 3 
 4 obliterate(...mortalEnemies);
 5 /*
 6 John Doe wiped out of the face of EXISTENCE as if 
 7 it had never existed.... Woooo
 8 cute puppy wiped off of the face of the earth
 9 etc...
10 */

Note how the spread operator ...mortalEnemies is super similar to rest parameters syntax but performs the opposite operation, instead of gathering arguments into an array, it spreads an array into arguments.

Concluding

Congratulations! You have cleared another obstacle in the path to writing functions with beautiful and thoughtful APIs.

Function parameters and arguments are yet another example of the flexibility and freedom that JavaScript offers. In JavaScript you can call a function with as many argument as you want regardless of the signature of the function itself.

In some ocassions you’ll need to design a function that takes an arbitrary number of arguments. If you are using ES5, you can take advantage of the arguments object. The arguments object is present in every function and gives you access to the arguments with which a function was called. Unfortunately, it is an array-like object and you may need to convert it to an array before you can use it. If you are using ES6 or above, rest parameters offer a great developer experience similar to C# params. You can combine rest parameters with normal parameters and even call one of these special functions with an array using the spread operator.

In the next chapter you’ll find out how to override functions (and methods) in JavaScript.

Exercises

More Useful Function Patterns: Function Overloading

One same API,
to provide similar function,
that's a smart thing, 
memorable, familiar, consistent
  
        - Siwelluap
        Chieftain of the twisted fangs

Have you Heard About The Marvels Of Overloading?

In the last couple of chapters we learned some useful patterns with functions in JavaScript that helped us achieve defaults and handling arbitrary arguments. We also saw a common thread: The fact that ES6 comes with a lot of new features that make up for past limitations of the language. Features like native defaults and rest parameters that let you solve these old problems in a more concise style.

This chapter will close this section - useful function patterns - with some tips on how you can achieve function overloading in JavaScript.

Function overloading helps you reuse a piece of functionality and provide a unified API in those situations when you have slightly different arguments yet you want to achieve the same thing. Unfortunately, there’s a problem with function overloading in JavaScript.

The Problem with Function Overloading in JavaScript

There’s a slight issue when you attempt to do function overloading in JavaScript like you would in C#. You can’t do it.

Indeed, one does not simply overload functions in JavaScript willy nilly. Imagine a spell to raise a skeleton army:

1 function raiseSkeleton(){
2   console.log('You raise a skeleton!!!');
3 }

And now imagine that you want to overload it to accept an argument mana that will affect how many skeletons can be raised from the dead at once:

1 function raiseSkeleton(mana){
2   console.log('You raise ' + mana + ' skeletons!!!');
3 }

If you now try to execute the raiseSkeleton function with no arguments you would probably expect the first version of the function to be called (just like it would happen in C#). However, what you’ll discover, to your dismay, is that raiseSkeleton has been completely overwritten:

1 raiseSkeleton();
2 // => You raise undefined skeletons!!!

In JavaScript, you cannot override a function by defining a new one with the same name and a different signature. If you try to do so, you’ll just succeed in overwriting your original function with a new implementation.

How Do We Do Function Overloading Then?

Well, as with many things in JavaScript, you’ll need to take advantage of the flexibility and freedom the language gives you to emulate function overloading yourself. In the upcoming sections you’ll learn four different ways in which you can achieve it, each with their own strengths and caveats:

1. Inspecting arguments
2. Using an options object
3. Relying on ES6 defaults
4. Taking advantage of polymorphic functions

Function Overloading by Inspecting Arguments

One common pattern for achieving function overloading is to use the arguments object to inspect the arguments that are passed into a function:

 1 function raiseSkeletonWithArgumentInspecting(){
 2   if (typeof arguments[0] === "number"){
 3     raiseSkeletonsInNumber(arguments[0]);
 4   } else if (typeof arguments[0] === "string") {
 5     raiseSkeletonCreature(arguments[0]);
 6   } else {
 7     console.log('raise a skeleton');
 8   }
 9 
10   function raiseSkeletonsInNumber(n){
11     console.log('raise ' + n + ' skeletons');
12   }
13   function raiseSkeletonCreature(creature){
14     console.log('raise a skeleton ' + creature);
15   };
16 }