DEV Community: Kishor Neupane

Coffee and Null

Kishor Neupane — Sat, 13 Feb 2021 10:43:44 +0000

Like everyday I started my morning with some coffee and tech articles(or talks) in pursuit of improving myself as a developer. Although, I am not into coffee, I have found that good engineers always have it so in hopes of becoming one, I now have it daily. And I think with that rate, I will be a decent one soon. If not, at least I will be a caffeine addict instead of becoming null.

The video was about writing better code and it was pretty good. The context was to improve a piece of javascript code given below. The function would take a number and we need to convert that number into a string such that negative number is parenthesized. (For eg: input of -10 gives output as (10), input of 5 gives output as 5).

function toParenthesized(n){
    if(n < 0){
        return '(' + Math.abs(n) + ')'
    }else if(n >= 0){
        return n
    }
}

Think about the problems this snippet has. One issue is with redundant if-statement for n >= 0 since we already checked for n < 0. Another issue is if we pass a positive number, the function returns a number type but it returns string when the input is negative. The major issue with this code is it does not handle the different types of data the user might pass in this function.
What if the user passes null or undefined?!

let x = null;
toParenthesized(x); // null
toParenthesized(); // undefined

So, the obvious thing to do is handle null and undefined. But before that, lets explore a bit about them.

Exploring null and undefined

null and undefined both are primitive data types in javascript. 'null' represents an absence of any value. 'undefined' represents a variable or object that is declared but not defined( not initialized).

let x = null; // null
let y;

console.log(x); // null
console.log(y); // undefined

Now, lets see how we can actually check whether a certain value is null or undefined. We know we can use typeof operator for primitives.

let x = null;
let y;

console.log(typeof x); // object , wtf?!
console.log(typeof y); // undefined

But 'typeof x' gave us 'object'! Its actually a bug and has been for a long time since the first version of javascript. It has not been fixed because it would break a lot of existing code. The gist is that we cannot use typeof operator for 'null' even if its a primitive. Maybe we can use equality operators!

let y;

console.log(x == null); // true
console.log(x === null); // true
console.log(y == undefined); // true
console.log(y === undefined); // true
console.log(x == y); // true
console.log(x === y); // false

This means that we can use loose equality operator to check for null and undefined at the same time. So, lets see refactor the snippet we started with.

// wraps a negative number with a parenthesis removing '-ve' sign
function toParenthesizedString(num){
    if(num == null) return; // handle null or undefined
    if(num < 0) return `(${Math.abs(num)})`;
    return num.toString();
}

It seems like we have fixed all the issues. However, a function is meant to be used somewhere else. What if the returned value of this function is used somewhere else and the returned value is undefined? We arrived at the same problem we started with!
So, now the solution might not be obvious and relies on the practice and architecture. The above code is fine if there is some sort of layer for input validation. But my preference in this case would be to throw an error so that I would catch it early in development.

function toParenthesizedString(num){
    if(num == null) throw new Error('Invalid input!'); // handle null or undefined
    if(num < 0) return `(${Math.abs(num)})`;
    return num.toString();
}

There are still few things we can improve. We could also return some default value instead of throwing error. The naming convention, usage of if(one liners or not), ternery operators and so on and many of these depend on preferences I guess so I'll leave that to you.

Conclusion

It is pretty important to understand null and undefined as a javascript developer. Since, they are going nowhere, in my opinion I would follow these:

Avoid null initialization if possible
Always put validation logic somewhere in the application based on the design
Fail as early as possible and,
Drink more coffee!

Prototypal 'inheritance'

Kishor Neupane — Fri, 15 Jan 2021 06:15:06 +0000

Inheritance in general, implies 'copying' certain behaviors from a class to create new objects. For every single object(instance) that is created from a certain class, the attributes and behaviors are 'copied'. Class-based languages like C++, Java, etc implement this mechanism of object creation where each object is a separate 'copy' of a class. In languages like Javascript, there is no concept of class! Still, Javascript is object oriented. Object creation and manipulation is pretty simple in Javascript.

However, implementing concepts like inheritance is not so straightforward. Javascript is a Prototype-based language, meaning it does not have classes, it only deals with objects. So, the way inheritance works in Javascript is by the use of links or references to the other objects to use or share behaviors.

Prototypes

Every object has a hidden property [[Prototype]] that references some object. Double braces in [[Prototype]] means its internal/hidden. Internal properties are not part of ECMAScript(a standard for scripting languages like Javascript), which means we cannot use it as an identifier in our code. But, in this case, we can access the hidden property [[Prototype]] with the help of _proto_ property(dunder proto) which is available to every object in Javascript. _proto_ is just a getter/setter for our hidden property [[Prototype]].

var person = {
    name: 'Keanu',
    age: 35
}
console.log(person);
console.log(person.hasOwnProperty('name'));

If you see the console, you should see a person object with a proto property along with the name and age properties. The code person.hasOwnProperty('name') works and actually returns true even though we have not defined 'hasOwnProperty' method on our person object. This is due to the _proto_ property which points to 'Object.prototype'. 'prototype' in 'Object.prototype' is just a property of 'Object' constructor function that happens to point to some other object. Remember a function is an object too!

Every function in Javascript has a 'prototype' property(when 'new' is used to create objects). Every object in Javascript has a _proto_ property.

Basically in Javascript, almost all objects are 'instances' of 'Object' which means all objects inherit from Object.prototype. If a certain property is not found in an object, Javascript tries to look that property in the object referred by _proto. Since 'Object.prototype' is pointed by __proto_ and 'Object.prototype' has a method called'hasOwnProperty', person.hasOwnProperty('name') works fine.By default, every object in Javascript has a _proto_ which points to 'Object.prototype' which we can see from our example.

This is the core concept of prototypes. If you want to inherit stuff, you need _proto_ to point to the object whose properties you want. The object
pointed by _proto_ is called a prototype object or simply a prototype. That's it.

Inheritance in action

var vehicle = {
    color: 'red',
    run: function(){
        console.log('Vehicle running.');
    }
};

var truck = {
    carryStuff: function(){
        console.log('Truck is carrying stuff.');
    }
};

truck.__proto__ = vehicle; // set [[Prototype]]
truck.run(); // truck runs too!
console.log(truck.__proto__ === vehicle); // obviously!
console.log(truck.__proto__.__proto__ === Object.prototype); // true

So, truck.run works because we have pointed _proto_ to vehicle object. Since, run() is not available in truck, javascript looks up in the 'prototype chain' untill it reaches the end, which is our good old 'Object'.

We used object literals in above example but now lets use constructor functions to simulate inheritance for reusability.

// a 'constructor' function
function Vehicle(color, price){
    this.color = color;
    this.price = price;
    this.run = function(){
        console.log('Vehicle is running!');
    }
  }

Since we want 'run' method to be availabe for child 'class', we put it in a prototype property so that it can be inherited.

function Vehicle(color, price){
    this.color = color;
    this.price = price;
}

Vehicle.prototype.run = function(){
    console.log('Vehicle is running!');
}

// child class
function Car(color, price, fuelType){
    this.color = color;
    this.price = price;
    this.fuelType = fuelType;
}

Car.prototype = Object.create(Vehicle.prototype);

Object.create() creates a new object with [[Prototype]] set to its first parameter, in this case 'Vehicle.prototype'.

var ferrari = new Car('red', 45465413, 'petrol');
ferrari.run(); //works
console.log(ferrari.__proto__ === Car.prototype); // true
console.log(ferrari.color);
console.log(ferrari.price);

We can improve our car class. We are setting color and price in Car which is redundant since Vehicle already does that and we are inheriting from it. So, we can call Vehicle which sets color and price properties but changing 'this' of Vehicle object to 'this' of Car object.

function Car(color, price, fuelType){
    Vehicle.call(this, color, price); // calling Vehicle in Car's context
    this.fuelType = fuelType;
}
Car.prototype = Object.create(Vehicle.prototype);

var ferrari = new Car('red', 45465413, 'petrol');
ferrari.run(); //works
console.log(ferrari.__proto__ === Car.prototype); // true
console.log(ferrari.color);
console.log(ferrari.price);

Also, every prototype object has 'constructor' property which points to the constructor function back. This property points to the function it was created from. In our case for 'ferrari' object, its constructor should be 'Car'.

console.log(ferrari.__proto__.constructor); // Oops... Vehicle!

So, we should set the constructor property as well.

Car.prototype.constructor = Car;
console.log(ferrari.__proto__.constructor); // Car

So, overall our pattern for inheritance looks something like this in ES5.

// parent class
function Vehicle(color, price){
    this.color = color;
    this.price = price;
}

Vehicle.prototype.run = function(){
    console.log('Vehicle is running!');
}

Vehicle.prototype.honk = function(){
    console.log('Peep peep!');
}

// child class
function Car(color, price, fuelType){
    Vehicle.call(this, color, price); // its like calling super()
    this.fuelType = fuelType;
}
Car.prototype = Object.create(Vehicle.prototype);
Car.prototype.constructor = Car;

In ES6 inheritance is straightforward due to some syntactic sugar.

class Vehicle{
    constructor(color, price){
        this.color = color;
        this.price = price;
    }

    run(){
        console.log('Vehicle is running!');
    }

    honk(){
        console.log('Peep peep!');
    }
}

class Car extends Vehicle{
    constructor(color, price, fuelType){
        super(color, price);
        this.fuelType = fuelType;
    }

    someMethod(){
        console.log('Just some method of Car');
    }
}

var ferrari = new Car('red', 45465413, 'petrol');
ferrari.run(); // Vehicle is running!
console.log(ferrari.__proto__ === Car.prototype); // true
console.log(ferrari.color); // red
console.log(ferrari.price); // 45465413

In this way, with the help of prototypes, we can 'inherit' features for reusability in Javascript. Prototypal inheritance is useful in situations when we want add new properties after the creation of objects unlike classical inheritance. Also, developers can quickly customize objects without thinking much about the structure of the class itself. However, type checking is difficult in prototype based languages and object creation is a bit slower too. The concept of prototypes were built for simplicity and Javascript being a dynamic language, it is a perfect match.

Callbacks, Asynchrony and Javascript

Kishor Neupane — Sun, 03 May 2020 13:12:34 +0000

Callbacks

Callbacks are simply functions that are passed as arguments to some function which calls the "call back" function at some time.

function foo(somearg, callback){
  console.log(somearg);
  // ... maybe other stuff
  callback(); 
  // .. maybe other stuff
}

// callback function 
function cb(){
  console.log('I am the callback');
}

// calling our foo function that takes two arguments,
// one of them is our callback function,
// (reference to the callback function, to be precise)
foo('i am just an argument', cb);

// or we can implement foo() like this
// foo('i am just an argument', () => {
//   console.log('i am the callback.');
// });

Here, cb() is our callback function which is "called back" in other function called foo().One of the arguments foo() takes is callback that is reference to cb() which is called after some lines of code in our example.
Now lets see why we need callback functions.

Why do we need callbacks?

Lets say we want some action to happen when we finish some task. For instance, we want to upload ourphoto and post it. The sequence of this operation is: upload photo first and then post it. How can we achieve it?

function uploadImage(img, cb) {
console.log("Uploading image...");
// do some stuff to upload image
// ...
console.log("Image uploaded.");
cb(img);
// ...
}

// callback function
function postImage(img) {
console.log("Posting image: ", img);
}

uploadImage("/path/to/image.jpg", postImage);

We need to call postImage() after uploading the image but we dont know when exactly the image upload completes. Thats why we let uploadImage() know to call our callback after it does some image upload stuff.
But, can’t we just call the postImage() function(callback) without passing it, just like calling another function inside a function??

function uploadImage(img) {
console.log("Uploading image...");
// do some stuff to upload image
// ...
console.log("Image uploaded.");
postImage(img);
// ...
}

// callback function
function postImage(img) {
console.log("Posting image: ", img);
}

uploadImage("/path/to/image.jpg");

Yes, you could have done it, if you wrote uploadImage() yourself. If it was written by someone else or it is a part of a library, you could have been allowed to pass the callback that takes one argument(img). For example: map() method in Javascript takes a callback with three arguments(More on this: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map).

Synchronous and Asynchronous callbacks

Every example we have seen till now, we have used synchronous callbacks.It means we know when our callback is going to be called. In previous example, we know cb(img) gets executed after console.log("Image uploaded.").And one important thing to note here is, synchronous callbacks return value(in our example we didn't explicitly return anything, however). It means everything waits untill the function returns.This has very significant implications in single threaded language like Javascript.
Javascript is single threaded, which means it has one call stack.

Call stack is where functions get pushed and popped off for execution. We don't want to fill our call stack with loads of time consuming functions(CPU intensive tasks like image processing, I/O request, etc) at the same time. But Javascript is a language for the web. What's the point of it if it doesn't handle network requests efficiently since it only has one call stack? Does one call stack mean the user has to wait for 10 seconds to upload photo, meanwhile staring at the screen because nothing works untill the image is uploaded? Why implement just one call stack then, are Javascript creators that stupid?
All these questions can be answered by one function: setTimeout().

setTimeout() takes one callback and minimum time(in milliseconds) after which that callback is to be executed. More on why i said 'minimum' time later.
And one thing, setTimeout() is not a Javascript function. Its not present in the source code of JS engines like V8. -What?
Yeah, it is a web api(exposed by browser). We will talk about this later.

function foo() {
console.log("Before calling setTimeout().");
setTimeout(() => {
console.log("Log me after 3 seconds.");
}, 3000);
console.log("After calling setTimeout().");
}

foo();

We got output in the sequence:
Before calling setTimeout().
After calling setTimeout().
Log me after 3 seconds.

More questions?
Before answering all these questions, I want to introduce next very important thing in Javascript called 'event loop'. In short, event loop pushes a callback from callback queue if our call stack is empty. Thats it! Checkout this awesome talk on event loop: (https://www.youtube.com/watch?v=8aGhZQkoFbQ). Callback queue is where our callbacks get queued, not the synchronous callbacks, but essentially the callback we passed to setTimeout().

foo() is pushed into the call stack. In function foo, console.log('Before calling setTimeout().') executes first because it is pushed into the call stack and returns immediately logging the output(not much work!).Simple. When setTimeout() is called, it is also pushed into the call stack. But since setTimeout() is our special function, it gets some special treatement. It gets popped off immediately and the callback it takes is passed to the web api- not pushed to our call stack!!

Javascript runtime is shown in the figure below:

Web apis are provided by browsers(For eg, DOM, XMLHttpRequest, etc). So after 3 seconds, the web api sends the callback to the callback queue. Then the event loop picks the callback from callback queue and execute it in call stack if the call stack is empty. If it is not empty, it waits. Therefore, our callback takes 'minimum' of 3 seconds to execute. It might take more than 3 seconds due to the fact that call stack might not be empty when event loop picks the callback from callback queue.

So in our example, console.log('After calling setTimeout().') executes after setTimeout() is popped off. Meanwhile our callback goes through web api, then callback queue and finally picked up by event loop to get pushed and executed in the call stack.So console.log('Log me after 3 seconds.') executes last although the sequence of the program tells us otherwise. This type of callback is called Asynchronous callback.

Asynchronous callbacks run on another thread(access to threads provided by browser) after the function(setTimeout()) returns.But synchronous callbacks run before the function(eg: uploadImage()) returns.
One of the reasons Javascript is single threaded is, complexity - single thread means less complexity. Another reason is, Javascript was intended to do short and quick tasks, initially.

Lessons learned

Don't pile the call stack with useless time consuming stuff. Javascript is useful for I/O but not for CPU intensive tasks because more CPU time means more time spent by functions in call stack which means event loop cannot push callbacks to the call stack.
Another thing is, we need to know what type of callbacks we are using. Its developer's responsiblity to know how the callback needs to be implemented as per the api documentation. For example: Node.js implements error first callbacks.