DEV Community: Varun Dey

Property Descriptors in JavaScript

Varun Dey — Sun, 26 Apr 2020 00:36:45 +0000

Originally posted at my website.

Whether you are new to JavaScript or have been working with it since some time, the language never seems to amaze because of it's quirks. Let's look at one tiny contrived example:

const myArray = [1, 2, 3];
myArray.length; // 3

/**
* Adding a random property to the
* array like an Object it is.
*/
myArray.justForTheLulz = "lolwut";
Object.keys(myArray);  // [ "0", "1", "2", "justForTheLulz" ]

/**
* Let's try deleting the newly
* added property.
*/
delete myArray.justForTheLulz; // true
Object.keys(myArray); // [ "0", "1", "2" ]

/**
* Cool! Can I do the same with length?
*/
delete myArray.length; // false
myArray.length; // 3

Well ofcourse we can not just simply remove the length property from an Array.prototype but the question persists - how does the JavaScript engine knows which properties are safe to delete and which ones are not? Given it is a simple property and not a method invocation, what stops us from deleting any property from any JavaScript object? How is our custom property any different than the inbuilt ones?

Come Property Descriptors

Property descriptors in JavaScript are a way of defining our own property inside an Object which can be immutable and non-enumerable. Think of them as meta properties of a property i.e. you can choose which operations you want to allow on the property. You can do this by calling a static method defineProperty of Object. defineProperty takes three arguments:

object on which to define the property
property name which needs to be defined
configuration object for the property which needs to be configured

const myObject = {};
const configuration = {};
Object.defineProperty(myObject, 'myProperty', configuration);

The return type of defineProperty is again an object with your input property and the meta configurations applied to it. The configuration object can be either of two type:

Data descriptor
Accessor descriptor

Let's take a look on how each of them work.

Data descriptors

Data descriptors is a kind of property that may or may not be writable and enumerable. They take the following four parameters:

value: Value of the property. Defaults to undefined
writable: If the property value can be overridden. Defaults to false
enumerable: If the property can be enumerated upon. Defaults to false
configurable: If the property can be deleted or if the data descriptor can be converted to accessor descriptor or vice versa. Defaults to false.

const object = {};
Object.defineProperty(object, 'key', {
  value: 'value',
  writable: false,
  enumerable: false,
  configurable: false
})

object.anotherKey = 'anotherValue'

/**
* You can neither delete the object.key
* property, neither enumerate over it
*/
console.log(object); // { anotherKey: "anotherValue", key: "value" }
Object.keys(myObject) // [ "anotherKey" ]
delete myObject.key; // false
delete myObject.anotherKey; // true

Accessor descriptor

Accessor descriptor have a getter and setter property defined in an object which works as a function.

get: Function which works as a getter of the property. Called without any arguments and returns the value of property. Defaults to undefined
set: Function which works as a setter of the object property. Called with an argument to set the value of property. Defaults to undefined

Please note that a descriptor configuration can not have both of value or writable and get or set.

function NameKeeper(name){
  this.name = name;
  Object.defineProperty(this, "name", {
    get() {
      return name
    },
    set(val){
      name = val
    }
  });
};

const nameKeeper = new NameKeeper("Alice");
nameKeeper.name; // "Alice"
nameKeeper.name = "Bob";
nameKeeper.name;  // "Bob"

Building our own custom length property

So now we know how to build our custom property using meta properties, let's try to build our own property which works similar to Array.prototype.length. Given an array, our property should return it's length.

Object.defineProperties(Array.prototype, {
  valuesContainer: {
    value: [],
    writable: true,
    enumerable: true,
    configurable: true
  },
  customLength: {
    value: 0,
    writable: true
  },
  value: {
    get() {
      return this.valuesContainer;
    },
    set(val) {
      this.valuesContainer.push(val);
      this.customLength += 1
    }
  }
});

const arr = new Array();
arr.value = 1;
arr.value = 2;
arr.value; // [ 1, 2 ]
arr.customLength; // 2

Awesome! In this example we did the following things:

Create a container where we can store the elements of the array.
Create a getter and setter methods so that we can view and insert elements into array.
Our custom implementation of getting the length of Array using the above two points.

Note that I have used defineProperties here which is similar to defineProperty except that it can take multiple properties at once.

Getting property descriptors of an Object

Now if you want to view how the property descriptor of any property is listed, you can make use of getOwnPropertyDescriptors

Object.getOwnPropertyDescriptors(Array, 'prototype')

Difference from `Object.freeze`

Now you might be wondering what is the difference between defineProperty and Object.freeze? The answer is not so much. The reason is when you assign a property to an object using dot notation, it looks something like this:

const obj = {};
const obj.key = 'value';
Object.getOwnPropertyDescriptors(obj);
/**
* Output:
* {
*  configurable: true,
*  enumerable: true,
*  value: "value",
*  writable: true
* }
*/

And when you do Object.freeze on an object, it makes the object immutable and non configurable

Object.freeze(obj);
Object.getOwnPropertyDescriptors(obj);
/**
* Output:
* {
*  configurable: false
*  enumerable: true
*  value: "value"
*  writable: false
* }
*/

Conclusion

Although you might not use defineProperty extensively but it is always fun to understand how things work internally. Here we learnt different behaviours of properties and to also create our custom implementation of calculating Array length. Let me know in comments if this post was helpful to you. 😊

Destructuring JavaScript objects with default value

Varun Dey — Mon, 30 Dec 2019 18:48:48 +0000

Originally posted at https://varundey.me/blog/destructuring-and-default-values/

Destructuring introduced in JavaScript ES6 is a nifty trick to scoop out properties directly from an object as variables.

const obj = {
    a:1,
    b:2,
    c:3
};

const {a, b, c} = obj;

console.log(a, b, c); // 1 2 3

Destructure and assign default values - the naive way

But what if you have to do some validation checks on your destructured properties before doing any operation

const {a, b, c} = obj;

if(typeof a === 'undefined'){
    // assign a to something
}

if(typeof b === 'undefined'){
    // assign b to something
}

if(typeof c === 'undefined'){
    // assign c to something
}

// start the actual work

Destructure and assign default values - the JavaScript way

Though it works perfectly fine but it is boring and redundant. What if we could make use of default values (just like default arguments in functions) right at the time of destructuring objects so that our unpacked property is never undefined.

const obj = {a: 1, b: 2};

const {
    a = 'foo',
    b = 'bar',
    c = 'baz',
} = obj;

console.log(a, b, c); // 1 2 baz

Easy right? You just need to assign the values as and when you unpack it.

Destructure, rename and assign default values

Neat! But what if we want to rename a parameter and set a default value to it? Pay attention.

const obj = {a: 1, b: 2};

const {
    a: A="foo",
    b: B="bar",
    c: C="baz"
} = obj;

console.log(A, B, C); // 1 2 baz

Confusing? I bet it is. Here are the steps to it.

First we destructure properties of the object

const {a, b, c} = obj;

Next, we assign variables to these properties

const {a: A, b: B, c: C} = obj;

After that, assign the default value as how we did in the previous example

const {a: A="foo", b: B="bar", c: C="baz"} = obj;

And there you have it. Adding default values right at the time of unpacking objects.

Caveats

Please note that destructuring with default value only works when there is no property to unpack in the object i.e. the property is undefined. This means that JavaScript treats null, false, 0 or other falsy values as a valid property and will not assign default value to them.

const obj = {a: null, b: false, c: 0};

const {
    a = 1,
    b = 2,
    c = 3,
    d = 4
} = obj;

console.log(a, b, c, d); // null false 0 4

I hope this was informative and will help you when you need to do something similar. Let me know what you think about this post in the comments below. ✌️

Migrating from Jekyll to Gatsby

Varun Dey — Sat, 05 Oct 2019 16:04:00 +0000

After much hype, I recently migrated my website from Gatsby to Jekyll. This blog post is about why did I choose to migrate to Gatsby and what were the learnings along the way.

Year 2015

This was a time when I was an undergrad student in college. I was a back-end developer working with Python and had little or close to no knowledge of how front-end web works. This was a time when the only JavaScript I knew was through jQuery and that too had a hard time dealing with. I could somehow make JavaScript work by copying snippets from StackOverflow but did not (want to) understand why JavaScript is behaving the way it is behaving. Needless to say I did not like working with JavaScript and tried to avoid as much as I could. I loved Python and wanted to use it everywhere.

Year 2016

By this time, I started realising my naiveness and understood that Python can not be a solution for everything. There are certain problems that JavaScript solves well. During this time, I also needed a website as my portfolio to showcase my projects and interests for the oncoming placement season. I took this as an opportunity to learn JavaScript but soon realised that the scope of the entire project was just too big for me. I neither had an idea what my website should look nor had the expertise to build it. After much head banging, I found Jekyll - a simple ruby based static site generator. I started experimenting with it and found using it was super fun for me because I was already fluent with command line in my linux machine and I could associate Ruby gems and bundles with Python modules and pip. Also there were thousands of Jekyll based templates readily available. I liked Material theme by Lukas Himsel the best. I quickly forked the repo and built my own version of it. In this process, I also added few features to the original repo as part of Hacktoberfest 2016. My website was built and github-pages made it super easy to deploy because of it supporting Jekyll themes out of the box. Everything was good. I could easily add blog posts to my website and the build was reliable.

Year 2017

It was difficult writing blogs after joining my first company as an intern. I was 100% dedicated solving problems for our users and solving their pain points. The company rewarded me well and I got a full time opportunity to work there. Time to update my website. Remember the reliable build system? Yeah that was thrown out of the window. I could not even build my own Github repo on my new machine. Digging into the errors, it seemed the package version had changed over the course of a year and Ruby's magical syntax was also not proving to be helpful. I cleansed Ruby out of my machine and reinstalled it again. The whole process made me tear my hair out but I somehow made it work hoping it should work here after now. Since I also wanted to learn JavaScript, I made a few front end side projects.

Year 2018

I had started understanding the concepts of JavaScript and why it behaves the way it behaves. I also learnt React and was totally blown away by it. I wanted to use it for my website. But I had the same problem all over again. I did not have the UX expertise. But this time I knew where to look. Gatsby was the one framework I found which would suit my purpose. I tried experimenting with it but found it to be too cumbersome. I had to make the change cascade at different places to make something work and visible at all places. I did not experiment much with Gatsby hereafter. Meanwhile Jekyll was making me crazy with a new error message every time I wanted to update something. I just avoided updating my blog altogether.

Year 2019

Things were this bad that I had to experiment in production for my website for a change to be reflected. I also tweeted about it. This was a breaking point for me. I wanted to move to a build system which is more reliable. I opened Gatsby again and started looking for a theme which would fit my needs and I found a nice looking theme by Preston Richey. I spent few hours understanding the flow and updating the source code according to me. This time Netlify helped me with deploying my new website to my domain.

I now have my website built on React and the data being served as GraphQL queries but I still can't find a way to show my other repositories as pages to my domain. Hoping this won't be a breaking point again this time. ✌️

Can you solve this JavaScript problem?

Varun Dey — Tue, 10 Sep 2019 18:11:01 +0000

You can also find a copy of this post on my website

I recently came across this JavaScript brain teaser and I thought to share it with you folks.

Create a function which takes in a bunch of function as arguments and performs left to right composition on them. It then returns the result from a function which takes in a single argument on which it performs the composition.

Example:

const addOne = num => num + 1;
const substractTwo = num => num - 2;
const multiplyThree = num => num * 3;

const resp = compose(addOne, substractTwo, multiplyThree);
const result = resp(4);
console.log(result);    // 9

/**
This is similar to multiplyThree(substractTwo(addOne(4)));
*/

Fun right? It took me about 20 minutes to come up with a working solution without googling/pair coding. I used classic vanilla JavaScript, browser console as my editor and console.logs/break points for debugging. 😅 I certainly hope you can do better than that. I would recommend you to come up with your own working implementation before reading further.

Spoiler alert

I pen down my approach for this problem from this section onward. This is a walk through of how I solved it. This would be a good point to write your own solution before going through the steps. If you are stuck somewhere, you can probably jump to that section from the list below (assuming your approach is same as mine). Consider yourself warned I guess? 🤷‍♂️

Identifying the parts of the problem statement

So far by looking closely at the problem I know that:
1. I need to create a function
2. This function should take a bunch of function arguments
3. Should return a function
4. This return function should take the input value
5. Do the calculations
6. Return the result

Since for prototyping, I find it easiest to create a snippet in Chrome dev tools. I fired up my Chrome and created a snippet composition.js under Snippets section of Sources tab. I usually go via this route as it helps me set console.logs and put breakpoints without the need of creating an unnecessary web-app.

1. Creating a function

This is probably the easiest step. I will also set given example arguments as part of this step

const addOne = num => num + 1;
const substractTwo = num => num - 2;
const multiplyThree = num => num * 3;

const compose = () => {}

2. Unknown number of arguments

Now that I have my dummy function in place, I need to pass in unknown number of arguments to this. This is easy. The only way you can pass in unknown number of arguments in JavaScript function is ...args. This returns an array of passed arguments.

const compose = (...args) => console.log(args);

compose(1, 2, 3);

3. Return a function

Till now, I have set up a function which takes in a bunch of arguments and just prints them. It works till now. Now from the example given, it is evident that the final result lies in another function closure which seems to be returned from compose function.

const compose = (...funcs) => {
    return () => console.log(funcs)
}

const result = compose(addOne, substractTwo, multiplyThree);
result();

4. Making closure take the input

Now that I have created my closure, I need to make this take in an argument and I'll just verify that it is holding good till this point.

const compose = (...funcs) => {
    return n => console.log(funcs, n)
}

const result = compose(addOne, substractTwo, multiplyThree);
result(4);

5. Doing the calculations

This was the step where I spent most of my time. If you reached till here without looking at any of the steps above, congratulations! I would still recommend to give it your best shot before reading further.

Now that I have all my functions working and in place, I need to do the calculations somewhere. But where? Should it go inside compose function? Or should it reside in the closure? 🤔 Think Varun, think.

Look at the example closely. compose takes in function argument but they mean nothing without the input number. The closure is where we take in that argument. So the calculations should be part of the closure function.

Cool. But how do I go about that?

Hmmm.. Since we are composing functions left to right, I need to pass my input to the first function. The result of that should be passed as an argument to the second function and so on and so forth.

But how do I do that?

Seems like I already have the functions as a list of array and since I do not need to mutate these elements of the array, I can use a forEach.

Iteration 1

const compose = (...funcs) => {
    return n => funcs.forEach(func => console.log(func))
}

Iteration 2

const compose = (...funcs) => {
    return n => funcs.forEach(func => console.log(func(n)))
}

Now comes the tricky part. I need to pass the result of the function as the argument to another function. I will make advantage of the fact that closures have the scope of their parent function.

Iteration 3

const compose = (...funcs) => {
    return n => {
        let result;
        funcs.forEach(func => {
            result = func(n);
        })
    }
}

I set up a break point inside forEach, and realized my mistake. This won't work. This will take in the same input on every function argument and will just assign result to that function's return value. I need to make it input for the first argument and the result of that for the remaining ones.

Hmm. This seems like a simple if/else condition. But to do that, I will also need to set up index for the loop. Meh. I probably can do it in more JavaScript'y way.

Iteration 4

const compose = (...funcs) => {
    return n => {
        let result;
        funcs.forEach(func => {
            result = func(result || n);
        });
    }
}

From the breakpoint that I have set in the earlier iteration, I can see that it is working as expected. But remember, this won't work if you swap the operators for OR condition. Since we need to short-circuit the OR, we need to check if the result exists before the input. If we switch the operators, n will always be present before result and we will be back to iteration 3.

6. Return the result

We already have our answer stored in result variable. We just need to return it back to the caller. If you have reached till here, this should be really easy,

const compose = (...funcs) => {
    return n => {
        let result;
        funcs.forEach(func => {
            result = func(result || n);
        });
        return result;
    }
}

Aand we are done. My final solution with removing the extra brackets and making it more ES8 friendly looked like this.

const compose = (...funcs) => n => {
    let result;
    funcs.forEach(func => result = func(result || n));
    return result;
}

const addOne = num => num + 1;
const substractTwo = num => num - 2;
const multiplyThree = num => num * 3;

const res = compose(addOne, substractTwo, multiplyThree);
res(4);     // 9

// We can also curry it together
compose(addOne, substractTwo, multiplyThree)(5);    // 12

That's it. This example takes a good test of your JavaScript closure and currying skills. I am fairly certain that you can also do it using .reduce() but I always tend to forget how the arguments of reduce works and since I challenged myself not to open Google, I came up with this. Let me know how well you did in the comments. ✌️

Iterators, Generators and Iteration Protocol in Javascript

Varun Dey — Sat, 24 Aug 2019 22:48:02 +0000

This post was originally published on my website

If you have been writing JavaScript for a while, you might be well aware what data types are iteratables in JavaScript. If you are not or just can't remember from top of your head, it's String, Array, Map, Set and TypedArray.

But Varun, except String isn't everything here an implementation of Object?

Iterable protocol

You would be absolutely correct to think that. After all most data-types in JavaScript are derived from Object. So what makes Array, Map, Set and TypedArray an iteratable but not Object? Let's open up our console and find out.

Array.prototype[Symbol.iterator]
Map.prototype[Symbol.iterator]
Set.prototype[Symbol.iterator]
Int16Array.prototype[Symbol.iterator]
Object.prototype[Symbol.iterator]

You might have noticed that except the last statement, every line returns us a function. All the remaining object type have a property called Symbol.iterator up their prototype chain. Since this property is not available in Object it returns undefined. Thus, for an object to be iteratable, it must implement iterable protocol which means that the given object must have a Symbol.iterator up it's prototype chain. Symbol.iterator is a function which takes no argument and returns an Object. This returned Object should follow convention of iterator protocol.

Iterator Protocol

Iterator protocol states that for an iterator object, there is a standard way in which the values should be returned back. The object returned from Symbol.prototype is said to be adhering to iterator protocol if it has a method next which returns following two properties:

done [boolean] A boolean value denoting if the iteration sequence has finished
value Any value returned while iterating. Can be optional when done is true

Let's prove what we've learnt so far

const map = new Map()
mapIterator = map[Symbol.iterator]()
mapIterator.next          // function next()

This means that Map implements

Iterable protocol
- becuase it has Symbol.iterator in it's __proto__ chain.
Iterator protocol
- because iterable protocol returns an Object which has a method next in it.

Iteration protocol in action

Let's put our theory to test on some actual data types

const string = "Hello"
const stringIterator = string[Symbol.iterator]()
stringIterator.next()       // Object { value: "H", done: false }
stringIterator.next()       // Object { value: "e", done: false }
stringIterator.next()       // Object { value: "l", done: false }
stringIterator.next()       // Object { value: "l", done: false }
stringIterator.next()       // Object { value: "o", done: false }
stringIterator.next()       // Object { value: undefined, done: true }

We just proved that String implements both iterable and iterator protocol. Many constructs (for..of, spread, destructuring, yield, etc.) implements iteration protocol under the hood. You can try the same thing with other data types and the result will be similar.

const map = new Map()
map.set('a', 1)
map.set('b', 2)
const mapIterator = map[Symbol.iterator]()
[...mapIterator]

Custom iteratation protocol

So basically my object should have a property Symbol.iterator which is a method and should return me an Object which should have a next method in it, calling which should give me a done and value property? That shouldn't be hard to create.

Turns out, it isn't. 😄

const customIteratationProtocol = (start, end) => ({
    [Symbol.iterator]: () => {
        let startIndex = start;
        return {
            next: () => {
                if(startIndex !== end){
                    return {
                        value: startIndex += 1,
                        done: false
                    }
                }
                return {
                    done: true
                }
            }
        }
    }
});

const customIteratationProtocolInstance = customIteratationProtocol(1, 3);
const customIterationProtocolObj = customIteratationProtocolInstance[Symbol.iterator]()
customIteratationProtocolInstance.next();  // Object { value: 2, done: false }
customIteratationProtocolInstance.next();  // Object { value: 3, done: false }
customIteratationProtocolInstance.next();  // Object { done: true }

You can also implement either of iterable protocol or iterator protocol but that is generally not advisable as it might throw a run-time error if such an object is consumed by a construct which expects an iterable. An object which implements iterable protocol but does not implement iterator protocol is known as non-well-formed iterables.

Generators

Generators in JavaScript are a special kind of function whose execution is not continuous. They allow you to create an internal state in the function construct. The value from this function is returned only when it comes across a yield keyword. Generators are defined by function* syntax. Generator function can be instantiated n number of times but each instantiated object can iterate over the generator only once. You can't use generators with arrow functions though.

function* myGenerator(n) {
    let index = n;
    while(true) {
        yield index += 1;
    }
}
const myGeneratorObj = myGenerator(2);
myGeneratorObj.next().value;      // 3
myGeneratorObj.next().value;      // 4
myGeneratorObj.next().value;      // 5

Are generators really useful? 😕

Although iterators are a great concept of JavaScript engine, I personally never had to use generators in JavaScript. Also in a prototypical language such as JavaScript, I really do not understand the use case which ES6 generators tries to solve. In my opinion, generators bring a lot of complexity to the language because of the following reasons:

It creates a constructor
It then creates a method under that constructor
The value is finally inside the object of that method call

This creates a performance overhead and introduces lots of throwaway stuff. I think we can do away with generators by introducing a simple function factory. The above example can be rewritten as

const myGenerator = n => {
    let index = n;
    return () => index += 1;
}
const gen = myGenerator(2);
gen();      // 3
gen();      // 4
gen();      // 5

Conclusion

JavaScript has a lots of things going under its hood. Iterations is just one of them. If you would like to learn more about iterators and generators, I would recommend going through the official MDN docs. I would love to hear from you what you think about this post. Also if there is a particular use case which generator solved for you I would love to hear that as well. Happy coding! 😁

prototype, proto and Prototypal inheritance in JavaScript

Varun Dey — Sun, 11 Aug 2019 12:54:06 +0000

This post was originally published on my website

If you have spent some time with JavaScript, chances are that you have already seen or atleast heard about prototypes. If you are unsure about prototypes or what does it do, this article is just for you. In this article, I will try to help you understand working of JavaScript prototypes and in the process, try to explain what is prototypical inheritance and how does it work.

Before beginning, I hope that you are already aware that everything in JavaScript is a high level object. What this means is except null and undefined, everything in JavaSscript is derived from Object.

But Varun, how is that possible? We have several primitives in JavaScript like String, Number, Boolean etc. How can a data type, say Number, be derived from Object?

prototype and proto

To answer that, we need to first understand what is prototype. Prototypes in JavaScript is nothing but a special set of properties which an object holds (remember, almost everything in JavaScript is derived from Object). Each object holds it's own set of prototype properties. Let's see a very basic example of what I mean by that. Open your browser dev tools and try the snippets as you go along.

var fooFunc = function() {
    return {
        foo: 42
    }
};
fooFunc.prototype.bar = 'baz';
var fooVal = fooFunc();
console.log(fooVal);   // {foo: 42}
console.log(fooFunc.prototype);     // {bar: "baz", constructor: ƒ}

The second print statement gives you the example of prototypal inheritance in all it's beauty. Function fooFunc is derived from Object instance and has it's own set of properties with it i.e. {bar: baz} along with whatever it carried along when it instantiated from Object i.e. {constructor: ƒ}.

So if fooFunc is derived from Object, can I go up the chain and see Object's prototype?

Good question and absolutely you can. However one thing you need to keep in mind is that except JavaScript function type, every other prototype of an object resides in it's __proto__ property. Let's see what I mean by that.

console.log('prototype of fooFunc:');
console.log(fooFunc.prototype);     // {bar: "baz", constructor: ƒ}
console.log('prototype of Object:');
console.log(fooFunc.prototype.__proto__);   // {constructor: ƒ, __defineGetter__: ƒ, __defineSetter__: ƒ, hasOwnProperty: ƒ, __lookupGetter__: ƒ, …}

Do you see what I see? The last console statement returns an object with it's own set of special properties. This is nothing but prototype chain of Object. This confirms that we can actually traverse up the prototype chain and that our function fooFunc is derived from Object.

So what happens when I try to traverse the prototype chain of Object?

Let's see what happens:

console.log(fooFunc.prototype); // {bar: "baz", constructor: ƒ}
console.log(fooFunc.prototype.__proto__);// {constructor: ƒ, __defineSetter__: ƒ, …}
console.log(fooFunc.prototype.__proto__.__proto__);     // null

You see, Object in JavaScript is the top level construct. If you try to see what properties does Object's parent hold, you'll get null because there is no parent of Object.

At this point, I would like you to go back to the begining and co-relate everything till here to what I said earlier in the post.

Prototpyes in JavaScript are nothing but a special set of properties held by an object.

Prototypal inheritance

Now that you've understood how prototype works, prototypical inheritance should be pretty straight forward. Let's look at the following example:

var obj = function(){
    this.firstName = 'Varun';
    this.lastName = 'Dey'
}
obj.prototype.age = 25;
var nameObj = new obj()
console.log(nameObj.age);   // 25

Let's break down what is happening over here:

First off, we are defining a function obj.
Now we are also assigning another property age directly on obj's prototype chain.
We instantiate a variable called nameObj from obj. nameObj is an object which gets two properties appended to it namely firstName and lastName.
When I ask newObj for it's age property, it firstly goes into it's own object and tries to find it. Does it find age in nameObj object?
- No. So it goes up the chain, which is nameObj.__proto__ and looks for an age property in that object.
- It finds an age property over here because nameObj.__proto__ is exactly the same as obj.prototype.

And this is what JavaScript's prototypal inheritance is all about. Whenever you ask JavaScript to fetch you a key, it first looks into it's own object's property. If it does not find anything, it goes up to its prototypal chain (obj.__proto__) and tries to find that key among those properties, if it does not find it there, it goes one level up it's current prototypal chain (obj.__proto__.__proto__) and does the same thing. It keeps on repeating the same process until it reaches the Object's prototype chain and returns undefined from there if it can not find it even there.

Prototype pollution

This makes an interesting case of inheritance in JavaScript which is quite different than other class-based languages like Java/C++:

function parent(){
    return{
        foo: 42,
        bar: 'baz'
    }
}
child = new parent()

If you look closely, you will see that child is an instantiated object of parent. And parent ultimately is nothing but an instantiated method of Object. What this means is that child's' and parent's prototype's prototype is Object's prototype

child.__proto__ === parent.prototype.__proto__      // true

Now let's see one more example:

function parent(){
    return{
        foo: 42,
        bar: 'baz'
    }
}
parent.prototype.__proto__.baz = 'I should not belong here'
child = new parent()
console.log(child.__proto__)

Here you see a prime example of protoype pollution. I created a property baz directly on Object's prototype by going over function's prototype chain. Now this baz will be shared across all instances of Object and that is why if you see the console statement, you will find that along with other Object properties, we now also have baz: "I should not belong here". This is a bad practice and is frowned upon as it breaks encapsulation.

Similarly I can also do this and JavaScript would allow me to do so:

function parent(){
    return{
        foo: 42,
        bar: 'baz'
    }
}
delete parent.prototype.constructor
child = new parent()

Performance

Needless to say, as you traverse up your prorototype chain, the lookup time increases and hence the performance suffer. This becomes critical when you are trying to access a non existent property across the full prototypal chain. To check whether the property you need is defined in the object itself, you can use hasOwnProperty.

child.hasOwnProperty('foo');    // true
parent.hasOwnProperty('baz');   // false
Object.prototype.hasOwnProperty('baz'); // true

Completing the circle

In the very beginning, I said that except null and undefined, everything is Object instantiation. Let's prove that:

const foo = 42;
const bar = 'fooBar';
const baz = true;
foo.__proto__.__proto__ === bar.__proto__.__proto__;    // true
bar.__proto__.__proto__ === baz.__proto__.__proto__;    // true

So you see what I'm talking about. Almost everything in JavaScript comes from Object

Conclusion

Prototypes makes the fundamental blocks of JavaScript. I hope I was able to help you understand the how prototypes work in JavaScript. Once you get the proper hang of it, you can extend this knowledge to understand how this works in JavaScript. Mozilla has an excellent resource on this and I encourage you to go through it as well - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain

I would love to hear if this article helped you in understanding JavaScript better. :)

DEV Community: Varun Dey

Property Descriptors in JavaScript

Come Property Descriptors

Data descriptors

Accessor descriptor

Building our own custom length property

Getting property descriptors of an Object

Difference from Object.freeze

Conclusion

Destructuring JavaScript objects with default value

Destructure and assign default values - the naive way

Destructure and assign default values - the JavaScript way

Destructure, rename and assign default values

Caveats

Migrating from Jekyll to Gatsby

Year 2015

Year 2016

Year 2017

Year 2018

Year 2019

Can you solve this JavaScript problem?

Example:

Spoiler alert

Identifying the parts of the problem statement

1. Creating a function

2. Unknown number of arguments

3. Return a function

4. Making closure take the input

5. Doing the calculations

Iteration 1

Iteration 2

Iteration 3

Iteration 4

6. Return the result

Iterators, Generators and Iteration Protocol in Javascript

Iterable protocol

Iterator Protocol

Iteration protocol in action

Custom iteratation protocol

Generators

Are generators really useful? 😕

Conclusion

prototype, __proto__ and Prototypal inheritance in JavaScript

prototype and __proto__

Prototypal inheritance

Prototype pollution

Performance

Completing the circle

Conclusion

Difference from `Object.freeze`

prototype, proto and Prototypal inheritance in JavaScript

prototype and proto