DEV Community: Kushan Joshi

How I learned to Stop Looping and Love the Iterator

Kushan Joshi — Wed, 30 May 2018 06:37:14 +0000

Let us all take out a minute from our busy lives to look at past and think how many hours did we waste fixing that for loop. If your memory returns an empty array have a look at this one. (Spoiler alert!, it sums the two consecutive elements of an array and for the first element it pairs it with the last element.)

 for (var i = 0, len = grid.length, j = len - 1, p1, p2; i < len; j = i++) {
    p1 = grid[i];
    p2 = grid[j];
    sum += p1 + p2;
}

The Problem with `for loop`

The biggest problem, in my opinion, is that they are too powerful. You can easily end up with a wrong for loop configuration which might deceivingly work, only to explode later in your production stack.

In short, the surface area of for loop is so wide that it is a bug magnet.

Functional Alternatives

90% of the times you can always convert that good old for loop into a nice good looking .map/.reduce. There are a very few places where things could go wrong with this approach.

for (var i = 0; i < array.length; i++) {
    array[i] = array[i] * 2;
}

array = array.map(o => o * 2);

The Iterable Approach

A functional alternative should be your first choice in getting rid of for loops, but there are times when you want to stick to it:

You feel performance is critical. For loop is still fastest but only by a very small margin.
You want to break;/continue; out of loop easily.
Certain complicated objects (Sets, Map, NodeList) don't really have a straightforward way of looping through them.

The smart ECMAScript folks knew about these limitations and probably many more, so they came up with an iteration protocol in ES2015.

What is a protocol anyway?

Javascript doesn’t have formal protocols like other languages. Think of it as a convention, like how node programmers like to follow error first callback.

Introducing iterables

Iterables are everywhere in javascript, you have been using them unknowingly. Anything which has a Symbol.iterator property is iterable.

Let us look at the simplest iterable, a string!


str = 'hello world';
iterator = str[Symbol.iterator](); // StringIterator {}
iterator.next(); // gives `h`
...
...
iterator.next(); // gives `d`
iterator.next(); // gives `undefined` as no more string left.

string type in javascript comes baked in with iteration protocol, which means we can now say strings are iterable.

What is Symbol and Symbol.iterator?

This topic is worthy of an article itself, but in short Symbol solves the problem of sneaking in a property into an object which you do not want to clash with any existing property. Visit MDN web docs for more info

So no more putting @@@@@\_my\_hidden\_property\_ in your objects!

Symbol.iterator is a globally available constant for anyone to use and implement the iteration protocol. So you can use it to make your own object implement iteration.

How do I implement the iteration protocol for my custom objects?

class Rand {
  [Symbol.iterator] () {
    let count = 0;
    return {
      next: () => ({ 
        value: count++, 
        done: count > 5
      })
    };
  }
}
var rand = new Rand();
var iterator = rand[Symbol.iterator]();
iterator.next();// {value: 0, done: false}
iterator.next();// {value: 1, done: false}
// .. 
iterator.next();// {value: 5, done: false}
iterator.next();// {value: undefined, done: true}

Don't let the syntax bog you down. Let us break this example down:

[Symbol.iterator] () This weird looking syntax is nothing but a new ES2015 way of initializing properties dynamically. (Look here more information.)
The Symbol.iterator method must return an object { next } (Don't forget this is all a convention/protocol). We call this object iterator. (More on this in the next section)
The .next() is simply incrementing the count every time it is called and it toggles done to true when the count exceeds 5.

What is the difference between `iterable` & `iterator` ?

Repeat after me,

Iterable is an object which implements the iteration protocol. string, Array, Set, Map are all iterables!

class Rand {
  [Symbol.iterator] () { // Rand has `Symbol.iterator` method, hence it is an iterable!
    let count = 0;
    return { // The return value is called an `iterator`
      next: () => ({ 
        value: count++, 
        done: count > 5
      })
    };
  }
}

Iterator is the thing which is returned by [Symbol.iterator]() of an iterable.
- It contains useful state information about where the current iteration is and what value to provide next.
- Any iterator must have a .next method on it (remember this is all a convention?), which would be used to get the next value out of it.
- The object returned by the .next() method must be {value, done}, where value is the current value and done tells whether iteration has finished or not.

var iterator = rand[Symbol.iterator](); // I am an iterator

iterator.next(); //  {value: 0, done: false}
iterator.next(); //  {value: 1, done: false}
...
iterator.next(); //  {value: 4, done: false}
iterator.next(); //  {value: undefined, done: true}

What do I get out of this complicated protocol?

You get a lot of superpowers for free if you enable iteration in your custom object or use any of Javascript's inbuilt iterables like Array, string, Map or Set.

1. Super Power: Spread it

Remember the class Rand that we just defined above? Since it is an iterable it inherits the spreading super powers. Visit MDN web docs for more info on spread.

var rand = new Rand();
var myArray = [...rand]; // [0, 1, 2, 3, 4] 

// string can also be used since it is an iterable
[..."kushan"]; // ["k", "u", "s", "h", "a", "n"]

Note: We didn't do [...rand[Symbol.iterator]()], since ... expects an iterable and not iterator.

2. Super Power: Use Array.from

Array.from(rand); // [0, 1, 2, 3, 4]
Array.from("kushan"); // ["k", "u", "s", "h", "a", "n"]

3. Super Power: for of loop

for of is a new looping mechanism introduced in ES2015, which only understands iterables. It automagically calls Symbol.iterator, stores the iterator behind the scenes and calls .next for you. It also stops when the iterator returns {done:true}.

for(const v of rand) {
  console.log(v); 
}
/*Output*/
// 0
// 1 
// ..
// 4

Unlike spread operator, for of loop can accept both iterable or iterator.

var map = new Map([['a', 1], ['b', 2]]); 

map[Symbol.iterator];// map is iterable because it has the `Symbol.iterator` key 

// `for of` loop understands `iterable`
for (const [key, val] of map) { 
    console.log(key, val); // 'a', 1
}

// `for of` loop also understands iterators
var iterator = map[Symbol.iterator](); // returns an iterator
for (const [key, val] of iterator) {
    console.log(key, val); // 'a', 1
}

// .keys() is a part of `Map` api
var keyIterator = map.keys();   // returns an iterator
for (const key of keyIterator) {
    console.log(key); // 'a'
}
// .values() is a part of `Map` api
var valueIterator = map.values();   // returns an iterator
for (const val of valueIterator) {
     console.log(val); // 1'
}

4. Super Power: Destructuring

This is one of my favourite for demoing super powers of iterables. ES2015 introduced destructuring assignment, which is built on top of iterables. You can only destruct iterables!

// array is iterable
[a, b] = [10, 20]; // a=10, b=20

// our custom class rand is Destructable :P
[a, b, c] = rand; // a = 0, b = 1, c = 2

// you can do fancy things like
[a, ...b] = rand; // a = 0, b = [1, 2, 3, 4]

Summary

Please share any other super power that you get for free when using iterables. I hope this article helped you understand iterables & iterators.

Don't forget to check out my previous articles.

If you ❤️ this article, please share this article to spread the words.

Javascript Underdogs: Part 1 - The WeakMap

Kushan Joshi — Wed, 11 Apr 2018 00:18:02 +0000

Hello 2018! It has been 3 years since we first saw Javascript 2015 (aka ES6). During this time most of us have focused on the cosmetic changes like Arrow => Functions or the fancy destructing operator … .

Everyone needs something exciting like the upcoming fancy |> pipe operator. Who cares if ES6 also added things like WeakMap, WeakSet, Iterables, Map or Set. Even looking at this thing called WeakMap, feels so depressing 😞.

Keeping the sarcasm aside, let us talk about WeakMaps💃.

Why you would need something Weak

I have to agree the name WeakMap is definitely a misnomer. If it were me I would have named it SuperMap. Before we get into definitions, let us actually take a moment and understand why we need WeakMap's in our apps.

Imagine it’s 1990 🏡 and you create an app of all the countries 🎌 present at that time.

var USSR = {
  name: 'Soviet Union',
  capital: 'Moscow',
  ..
  ..
}

var countries = [ Afganishtan, Albania, Algeria, ..., USSR, ..., Zimbabwe ]

A user can click any country and get detailed information which also includes the area of the country. Below is a hypothetical area calculation function.

async function calcArea(country) {
  const boundaries = await fetch(country);

  area = calculateArea(country, boundaries); // takes a long time

  return area;
}

Caching the Area

Every time a user clicks a country you calculate the area. But we have a problem! If a user clicks a country multiple times you have to repeat this enormous asynchronous calculation, which is something we should totally avoid. There are generally two ways to solve this kind of problem.

Debounce the function
Cache the function

Debouncing is a peaceful way to calm down multiple aggressive invocations in a short interval of time. (Imagine an impatient user clicking the refresh button multiple times). Debounce allows us to only take the last invocation and discard the rest.

Since countries don't change area that often, we can simply cache the result of calcArea.

We can use both caching and debouncing to make our application performant. Below is a generic caching function which we will use to cache calcArea.

function cachify(fn) {
  // its a good idea to hide you cache inside the closure
  var cache = new Map();
  return arg => {
    if (cache.has(arg)) {
      return cache.get(arg);
    }
    var computed = fn(arg);
    cache.set(arg, computed);
    return computed;
  };
}

cachedCalcArea = cachify(calcArea);

cachedCalcArea(USSR); // goes and computes the area
cachedCalcArea(USSR); // already computed, returns the cached area

Great! We made some serious performance improvements.

But we have another problem, USSR just broke into 15 new countries. This would mean we remove USSR and add the newly formed countries to our countries array.

countries.remove(USSR);
// add the new countries
countries.add([Armenia, Azerbaijan, ...., Uzbekistan]);

Removing USSR just from the array doesn't help, as our cache still contains USSR and the calculated area. A naive solution would be to monkey patch our cachify function to remove USSR, but if the world continues to break into smaller countries we have got ourselves a memory leak.

We need a smart way to clean up our cache which scales well. There are multiple ways fellow developers would approach this problem:

Maintain a precomputed area array and keep it in sync with countries.
Figure out some smart cache eviction like LRU, time-based, etc.

Precomputing the area for every country seems to be a waste of computation, as most of the users won't ever be seeing every country.

We can use a smart caching strategy like Least Recently Used caching, this caching automatically removes the entry which is least recently used. But we aren't running out of memory with 160+ countries and LRU doesn't seem all that magical and seamless.

What about WeakMap?

WeakMap is the missing jigsaw piece for our caching problem. It automatically removes* any unused references from it.

"The WeakMap object is a collection of key/value pairs in which the keys are weakly referenced. The keys must be objects and the values can be arbitrary values." - MDN

I like to say WeakMap is nothing but a regular Map with dementia. It is a very forgiving data structure, it will forget things which no longer matter. (We should be like that too :P)

We can simply replace the Map with WeakMap in our caching function.

function weakCache(fn) {
  var cache = new WeakMap(); // <-- Behold the Weak!
  return (arg) => {
    if (cache.has(arg)) {
      return cache.get(arg);
    }
    var computed = fn(arg);
    cache.set(arg, computed);
    return computed;
  }
}
cachedCalcArea = weakCache(calcArea);

cachedCalcArea(USSR); // cache miss
cachedCalcArea(USSR); // cache hit

Now let USSR break into the 15 countries. We just need to take care of removing all references pointing to the USSR obj in our app and our cachedCalcArea function will automatically forget the USSR entry in the cache. Hence, avoiding the memory leak!

How does it forget things?

WeakMap works similar to a regular Map but in order to be a forgetful version of Map it imposes these constraints:

Primitive data type keys are not allowed (Numbers, String, null, true, etc)
You cannot list all the values inside the WeakMap

Let us see a hypothetical example of WeakMap

Imagine a WeakMap instance to be a building with thousands of 🚪 doors.

  var building = new WeakMap();

Each door has a unique key and we own a key 🔑 for our 🚪101. Due to the constraints mentioned above the key can only be an object.

  var key = {
    password: '🔑'
  };

We can lock/unlock our door with this key.

  building.set(key, '🚪101');

  building.get(key); // 🚪101

Now a thief has seen our key (Its Javascript duh!) and he tries to fabricate a duplicate key.

  var fake_key = {
    password: '🔑'
  };

Since we live in a Javascript world we clearly know even though they look same, they are not equal.

  fake_key === key // false

Our thief didn't read this awesome article and he tries to get into our building using his fake key only to fail :(.

  building.get(fake_key); // undefined

What happens if we lose the key

As long as some variable holds the reference to our original key we are safe. But if there comes a time when no variable in the entire app is holding a reference to our key, we lose the access to our 🚪101.

This is exactly what powers the smart caching of a WeakMap. If we lose the key, the GC can deduce that there is no way to access the thing associated with the key and it can safely remove it from the memory.

Note: This is the crucial difference between a WeakMap and Map. WeakMap removes <key,value>if you lose the key, but in a Map, you can simply list all the keys to find the lost key.

Coming back to USSR problem, when USSR breaks into the 15 countries and we just need to take care of removing all references to the USSR obj in our app.

countries.remove(USSR); // remove from array

USSR = undefined; // unset the variable

// at this point there is no way to get the cached area of USSR since it doesn't exist anymore

As you can see after the above steps, there is no way of accessing the USSR object in the current state of app and with this knowledge Javascript garbage collector automatically clears the memory it reserved for the area of USSR. Notice the removing happens behind the scenes and all we did was replace Map with WeakMap. Isn't that powerful?

WeakMap Takeaways

Remember not to mutate the key object because in Javascript the object reference stays the same even if you mutate the object.

var obj = {name: '🐕'};
weakMap.set(obj, 'animal');

obj.name = '🙍‍♂️';
weakMap.get(obj); // 'animal'

WeakMap cannot accept primitive javascript values as keys. You should use Map if you wanna use them as your key.

weakMap.set('key', 'value'); // Error!

Sometimes it is faster to not cache a function. If your function barely takes a millisecond to execute, you would end up slowing it down by caching.
You can use anything as a value for WeakMap/Map. Yes even promises!
The eviction of an unsued key doesn't happen immediately. It depends on the garbage collector's mood. You shouldn't worry about this part though.
WeakMap works great for derived state. A lot of times your application has state which can simply be derived from other state. In example below, you can see deriving a value using cached function is much more maintainable and easier to reason with.

var user = {
    name: "Kushan Joshi"
}

var websites = ['Facebook', 'Github', 'Twitter', 'Dev.to', 'Medium'];

var memberOf = (user) => websites.filter(website => isUser(user));

// save the websites and keep track of it, too complicated 🤮 !
user.memberOf = memberOf(user);

// deriving the value using weakMaps, awesomo 🤖!
cachedMemberOf = weakCache(memberOf); // avoid recomputing everytime
// or derive it everytime you need it
console.log(cachedMemberOf(user)); 
render(cachedMemberOf(user))

I really hope this article helped you in understanding WeakMaps. I love using it with libraries like Immutable.js or Redux since they enforce immutability. Even if you don't use these libraries, as long as you don't mutate the object you can reap benefits from WeakMap.

I am planning on writting a Part-2 of Javascript Underdogs, let me know in the comments what Javascript feature you think is amazing but underapreciated.

If you ❤️ this article, please share this article to spread the words.

Reach out to me on Twitter @kushan2020.

9 Promising Promise Tips

Kushan Joshi — Wed, 21 Feb 2018 14:02:11 +0000

Promises are great to work with! Or so does your fellow developer at work says.

This article would give you to the point no bullshit tips on how to improve your relationship with the Promises.

1. You can return a Promise inside a .then

Let me make the most important tip standout

Yes! you can return a Promise inside a .then

Also, the returned promise is automatically unwrapped in the next .then

.then(r => {
    return serverStatusPromise(r); // this is a promise of { statusCode: 200 }
})
.then(resp => {
    console.log(resp.statusCode); // 200; notice the automatic unwrapping of promise
})

2. You create a new Promise everytime you do .then

If you are familiar with the dot chaining style of javascript you would feel at home. But for a newcomer this might not be obvious.

In promises whenever you .then or .catch you are creating a new Promise. This promise is a composition of the promise you just chained and the .then / .catch you just attached.

Let us look at an example:

var statusProm = fetchServerStatus();

var promA = statusProm.then(r => (r.statusCode === 200 ? "good" : "bad"));

var promB = promA.then(r => (r === "good" ? "ALL OK" : "NOTOK"));

var promC = statusProm.then(r => fetchThisAnotherThing());

The relationship of above promises can be described neatly in a flow chart:

The important thing to note here is that promA, promB and promC are all different promises but related.

I like to think of .thening as a big massive plumbing where water will stop flowing to the children when the parent node malfunctions. For eg. if promB fails, no other node will be affected but if statusProm fails all the nodes will be affected i.e. rejected.

3. A Promise is resolved/rejected for EVERYONE

I find this as one of the most important thing that makes promises great to work with. To put it simply, if a promise is shared between multiple parts of your app, all of them would get notified when it gets resolved/rejected.

This also means nobody can ever mutate your promise, so please feel free to pass it around without worrying.

function yourFunc() {
  const yourAwesomeProm = makeMeProm();

  yourEvilUncle(yourAwesomeProm); // rest assured you promise will work, regardless of how evil uncle consumes your promise

  return yourAwesomeProm.then(r => importantProcessing(r));
}

function yourEvilUncle(prom) {
  return prom.then(r => Promise.reject("destroy!!")); // your evil uncle
}

In the example above you can see that promise by design makes it difficult for anyone to do nefarious things. As I said above, Keep calm and pass the promise around

4. Promise Constructor is not the solution

I have seen fellow developers exploiting the constructor style everywhere, thinking they are doing it the promise way. But this is a big lie, the actual reason is that the constructor API is very similar to the good old callback API and old habits die hard.

If you find yourself writing Promise constructors everywhere, you are doing it wrong!

To actually take a step forward and move away from callbacks, you need to carefully minimize the amount of Promise constructor's you use.

Let us jump to the actual use case of a Promise constructor:

return new Promise((res, rej) => {
  fs.readFile("/etc/passwd", function(err, data) {
    if (err) return rej(err);
    return res(data);
  });
});

Promise constructor should only be used when you want to convert a callback to promise.
Once you have grasped this beautiful way of creating promises, it can become really tempting to use it at other places which are already promisified!

Let us look at a redundant Promise constructor

☠️Wrong

return new Promise((res, rej) => {
    var fetchPromise = fetchSomeData(.....);
    fetchPromise
        .then(data => {
            res(data); // wrong!!!
        })
        .catch(err => rej(err))
})

💖Correct

return fetchSomeData(...); // when it looks right, it is right!

Wrapping a promise with Promise constructor is just redundant and defeats the purpose of the promise itself.

😎Protip

If you are a nodejs person, I recommend checking out util.promisify. This tiny thing helps you convert your node style callback into promises.

const {promisify} = require('util');
const fs = require('fs');

const readFileAsync = promisify(fs.readFile);

readFileAsync('myfile.txt', 'utf-8')
  .then(r => console.log(r))
  .catch(e => console.error(e));

5. Use Promise.resolve

Javascript provides Promise.resolve, which is a short hard for writting something like this:

var similarProm = new Promise(res => res(5));
// ^^ is equivalent to
var prom = Promise.resolve(5);

This has multiple use cases and my favourite one being able to convert a regular (sync) javascript object into a promise.

// converting a sync function to an async function
function foo() {
  return Promise.resolve(5);
}

You can also use it as a safety wrapper around a value which you are unsure whether it is a promise or regular value.

function goodProm(maybePromise) {
  return Promise.resolve(maybePromise);
}

goodProm(5).then(console.log); // 5

goodProm(Promise.resolve(Promise.resolve(5))).then(console.log); // 5, Notice it unwraps all the layers of promises automagically!

6.Use Promise.reject

Javascript also provides Promise.reject, which is a short hand for this

var rejProm = new Promise((res, reject) => reject(5));

rejProm.catch(e => console.log(e)) // 5

One of my favourite use case is rejecting early with Promise.reject.

function foo(myVal) {
    if (!mVal) {
        return Promise.reject(new Error('myVal is required'))
    }
    return new Promise((res, rej) => {
        // your big callback to promie conversion!
    })
}

In simple words, use Promise.reject wherever you want to reject promise.

In the example below I use inside a .then

.then(val => {
  if (val != 5) {
    return Promise.reject('Not Good');
  }
})
.catch(e => console.log(e)) // Not Good

Note: You can put any value inside Promise.reject just like Promise.resolve. The reason you often find Error in a rejected promise is that it is primarily used for throwing an async error.

7. Use Promise.all

Javascript provides Promise.all, which is a shorthand for …. well I can't come up with this 😁.

In a pseudo algorithm, Promise.all can be summarised as

Takes an array of promises

    then waits for all of them to finish

    then returns a new Promise which resolves into an Array

    catches if even a single fails/rejects.

The following example shows when all the promises resolve:

var prom1 = Promise.resolve(5);
var prom2 = fetchServerStatus(); // returns a promise of {statusCode: 200}

Proimise.all([prom1, prom2])
.then([val1, val2] => { // notice that it resolves into an Array
    console.log(val1); // 5
    console.log(val2.statusCode); // 200
})

This one shows when one of them fails:

var prom1 = Promise.reject(5);
var prom2 = fetchServerStatus(); // returns a promise of {statusCode: 200}

Proimise.all([prom1, prom2])
.then([val1, val2] => {
    console.log(val1); 
    console.log(val2.statusCode); 
})
.catch(e =>  console.log(e)) // 5, jumps directly to .catch

Note: Promise.all is smart! In case of a rejection, it doesn't wait for all of the promises to complete!. Whenever any promise rejects, it immediately aborts without waiting for other promises to complete.

😎Protip
Promise.all does not provide a way to execute promises in batches(concurrency), since by design promises are executed the moment they are created. If you want to control the execution, I recommend trying out Bluebird.map. (Thanks Mauro for this tip.)

8. Do not fear the rejection OR

Do not append redundant `.catch` after every .then

How often do we fear errors being gobbled up somewhere in between?

To overcome this fear, here's a very simple tip:

Make the rejection handling the problem of the parent function.

Ideally, rejection handling should be at the root of your app and all the promise rejections trickle down to it.

Do not fear writing something like this

return fetchSomeData(...);

Now if you do want to handle the rejection in your function, decide whether you want to resolve things or continue the rejection.

💘 Resolving a rejection

Resolving rejection is simple, in the .catch whatever you return would be assumed to be resolved. However there is a catch (pun intended), if you return a Promise.reject in a .catch the promise will be rejected.

.then(() => 5.length) // <-- something wrong happenned here
.catch(e => {
        return 5;  // <-- making javascript great again
})
.then(r => {
    console.log(r); // 5
})
.catch(e => {
    console.error(e); // this function will never be called :)
})

💔Rejecting a Rejection
To reject a rejection is simple, don't do anything. As I said above, let it be some other functions problem. More often than not, parent functions have a better way to handle the rejection than your current function.

The important thing to remember is, once you write a catch it means you are handling the error. This is similar to how sync try/catch works.

If you do want to intercept a rejection: (I highly recommend not!)

.then(() => 5.length) // <-- something wrong happenned here
.catch(e => {
  errorLogger(e); // do something impure
  return Promise.reject(e); // reject it, Yes you can do that!
})
.then(r => {
    console.log(r); // this .then (or any subsequent .then) will never be called as we rejected it above :)
})
.catch(e => {
    console.error(e); //<-- it becomes this catch's problem
})

The fine line between .then(x,y) and then(x).catch(x)
The .then accepts a second callback parameter which can also be used to handle errors. This might look similar to doing something like then(x).catch(x), but both these error handlers differ in which error they catch.

I will let the following example speak for itself.

.then(function() {
   return Promise.reject(new Error('something wrong happened'));
}).catch(function(e) {
   console.error(e); // something wrong happened
});


.then(function() {
   return Promise.reject(new Error('something wrong happened'));
}, function(e) { // callback handles error coming from the chain above the current `.then`
    console.error(e); // no error logged
});

The .then(x,y) comes really handy when you want to handle an error coming from the promise you are .thening and not want to handle from the .then you just appended to the promise chain.

Note: 99.9% of the times you are better off using the simpler then(x).catch(x) .

9. Avoid the .then hell

This tip is pretty simple, try to avoid the .then inside a .then or .catch. Trust me it can be avoided more often than you think.

☠️Wrong

request(opts)
.catch(err => {
  if (err.statusCode === 400) {
    return request(opts)
           .then(r => r.text())
           .catch(err2 => console.error(err2))
  }
})

💖Correct

request(opts)
.catch(err => {
  if (err.statusCode === 400) {
    return request(opts);
  }
  return Promise.reject(err);
})
.then(r => r.text())
.catch(err => console.erro(err));

Sometimes it does happen that we need multiple variables in a .then scope and there is no option but to create another .then chain.

.then(myVal => {
    const promA = foo(myVal);
    const promB = anotherPromMake(myVal);
    return promA
          .then(valA => {
              return promB.then(valB => hungryFunc(valA, valB)); // very hungry!
          })
})

I recommend using the ES6 destructuring power mixed with Promise.all to the rescue!

.then(myVal => {
    const promA = foo(myVal);
    const promB = anotherPromMake(myVal);
    return Promise.all([prom, anotherProm])
})
.then(([valA, valB]) => {   // putting ES6 destructing to good use
    console.log(valA, valB) // all the resolved values
    return hungryFunc(valA, valB)
})

Note: You can also use async/await to solve this problem if your node/browser/boss/conscious allows!

I really hope this article helped you in understanding Promises.

Please check out my previous blog posts.

If you ❤️ this article, please share this article to spread the words.

Reach out to me on Twitter @kushan2020.

One life saving Javascript Tip

Kushan Joshi — Tue, 06 Feb 2018 19:03:56 +0000

Always Exit Early !

function mostComplicatedFunction(data) {



    if (!data) {
      return; // << Always exit early whenever you can!
    }



    // Bang Bang!

    var {words, ii, position, word, current, sentence} = data;

    /**
     * @default 100
     */
    num_words = num_words || 100;

    words = [LoremIpsum.WORDS[0], LoremIpsum.WORDS[1]];
    num_words -= 2;

    for (ii = 0; ii < num_words; ii++) {
    position = Math.floor(Math.random() * LoremIpsum.WORDS.length);
    word = LoremIpsum.WORDS[position];

    if (ii > 0 && words[ii - 1] === word) {
        ii -= 1;
    } else {
        words[ii] = word;
    }
    }

    sentences = [];
    current = 0;

    while (num_words > 0) {
    sentence_length = this.getRandomSentenceLength();

    if (num_words - sentence_length < 4) {
        sentence_length = num_words;
    }

    num_words -= sentence_length;

    sentence = [];

    for (ii = current; ii < current + sentence_length; ii++) {
        sentence.push(words[ii]);
    }

    sentence = this.punctuate(sentence);
    current += sentence_length;
    sentences.push(sentence.join(" "));
    }

    return sentences.join(" ");

}

A toddlers guide to memory leaks in Javascript

Kushan Joshi — Mon, 05 Feb 2018 03:17:09 +0000

In this article I will take a very simplistic approach in understanding memory leaks and I will also attempt to diagnose them.

In todays world of abundant memory, we seldom worry about memory leakages. But I hate to tell you that we live in a real world and nothing comes for free.

Oh my fancy functional programming

Disclosure: I absolutely love functional programming.
Functional programming is cool and with the new ES6 syntax it becomes even cooler.

const arrayAddFirst = (a, b) => [a, ...b];

This example above looks super good. Unless you bro-program with me and I blindly put it inside a heavy duty loop 😎.

result = newData.reduce((p,r) => arrayAddFirst(r, p), []);

Now I don't want you to judge me for the idiot code above. (virtual hug if you can guess what it does 😁)


for(var i = 0; i < newData.length; i++) {
    for(var j = 0; j < i; i++) {
        // stuff here
    }
}

The above code snippet is the old fashion equivalent of our example. Notice how easy it is to see it will run n * (n+1) / 2 times, where n is the length of newData.

The main problem in the example code is that the garbage collector has to kick in frequently. The fancy [a, ...b] array you create every time in the .reduce loop needs to be removed from memory or else it will eventually consume all of the memory.

This example tries to shed light on the important fact that memory is not your best friend. It works in your favour 99% of the time, but when it decides to stab you, it directly stabs you in the eye.

Memory Leaks ….

Generally a javascript application can freeze in two ways:

Infinite loops: You might have accidently written a loop which never terminates.

var x = 0;
while(x < 5) {
   console.log(x); // Warning! do not try this at home 
}

Running out of memory: We all know there is limited amount of memory in a computer and if we are not careful we might end up hogging all of the memory.

var x = [ [1] ];
for(var i = 1; i < 100000; i++) {
    x.push(arrayAddFirst(i, x[i-1])); // Warning! do not try this at home 
}

Alright, but what about Memory Leaks??

Ofcourse, you can easily avoid these bad behaviours by being careful. But Memory leaks are one of those nasty devils which silently sit.

Let us define a computer which has infinite resources and let's call it Deep thought. We will refer to Deep thought in this article DT-42 and you will soon see how we will use DT-42 to figure out memory leaks.

Memory Leaks

A Memory leak in simple terms is forgotten data forever waiting to be used.
Let us see an example before we jump to a scientific definition.


function sayHi() {
    var allNames = [];
    var emoji = '👋';
    return name => {
        allNames.push(name);
        return emoji + name;
        }
}

In the example, our program is becoming fatter everytime we call it. The garbage collector is not able to cleanup allNames because the function needs it to push data. It cannot figure out that allNames would never be read and hence it is futile to give it any space in memory.

The Wikipedia says:

memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations[1] in such a way that memory which is no longer needed is not released.

I find it much easier to understand the concept by thinking of it as a symptom. Your program is the patient whose love for memory keeps on increasing without bound.

Most of the time the computer (Garbage Collector) is good enough to spot most of data that you wouldn't be using anymore and cleans it up for you. But it is not perfect and we are far from having a garbage collector smarter than humans. (If we did have one, it would be writting the code and not us :P)

Give me some real life leakages

The problem with our real life is that we don't encounter such trivial memory leaks and most often the leakages are lurking behind a seemingly well behaving piece of code (Something as innocent looking as arrayAddFirst). Instead of throwing some real life leakages I would rather show you how to identify a memory leak.

Let us fire Chrome to help diagnose memory leaks.

Open up an empty page.
Open the dev panel (Command+Option+I or Control+Shift+I)
Paste this example code in the console.

function sayHi() {
    var allNames = [];
    return name => {
            allNames.push(name);
            return '👋 ' + name;
        }
}
var hello = sayHi();
hello('Gandhi');

Alright, we have started leaking memory already, now let us open our memory profiler.

You should be able to find it as a memory tab in the dev tools.

For the scope of this article we will focus on Take Heap Snapshot. This functionality takes snapshot of the current memory usage of your program.

In my case it looks something like this:

Great, now we will run our innocent looking function a couple of times.

for(var i=0; i<1000000; i++) {
    hello('Gandhi');
}

If you take another snapshot, you will see an increased memory usage.

In my case there is a complete difference of 10 megabytes. In a lot of real life cases a jump of several megabytes might be normal and you might want to take multiple snapshots over a span of time to rule out a leak.

You can easily compare two snapshots by clicking on the Summary dropdown and switching to Comparison.

If you compare your new snapshot with the one you took earlier and put #Delta to descending, you will find a huge number in the (string). This is where our memory is leaking. Click on it and you will see a lot of Gandhi's.

I really hope this article helped you in understanding memory. This is just one of the several approaches one can take to diagnose a leakage. Please check out the following links for a more advanced take on memory:

If you ❤️ this article, please share this article to spread the words.

Reach out to me on Twitter @kushan2020.

Understanding Default Parameters in Javascript

Kushan Joshi — Sun, 19 Nov 2017 14:20:43 +0000

Javascript landed with native default parameters support with ES2015. Contrary to what one might think, it isn’t just a syntactic replacement for||(the logical OR operator).

Javascript before default parameters

Before the native support for default parameters, one would write something like this:

function filterEvil(array, evil) {
  evil = evil || 'darth vader';
  return array.filter(item => item !== evil);
}

To understand the code snipped above, one needs to keep the following things in mind:

Truthy/Falsy: Values in javascript can be categorized into truthy or falsy. In simple words, Javascript tries to convert a variable into a boolean value, to figure out the conditionals (eg. if, for loop). * Short Circuit Evaluation: The expression involving || is processed left to right. While processing left to right, the compiler is smart enough to not process the remaining items if it encounters a truthy value aka Short Circuiting.

In short, this is just a syntactic sugar for:

function filterEvil(array, evil) {
  if (!evil) {
    evil = 'darth vader';
  }
  return array.filter(item => item !== evil);   
}

The reason this method is so prevalent is that you can chain multiple ||’s and let short-circuiting take care of it. Imagine writing the same thing with if statements.

Now if your evil variable happens to be an empty string '' or any falsy value, the function above will assume it to be darth vader.

This can be okay in most cases, but it can cause those dreaded silent bugs in a more involving application. A great solution to this problem is within the language and it is called default parameters.

Javascript after default parameters

Let us use the same filterEvil example and see how it would look with default parameters.

function filterEvil(array, evil = 'darth vader') {
  return array.filter(item => item !== evil);   
}

At first glance, it looks neat and concise. But don’t let the looks deceive you! There is a lot going under the hood. It would be frivolous to assume that the default value would step in whenever evil is not supplied.

Let us look at some important details,

1. Distinction between null and undefined.

Javascript has two answers to the not present problem, null and undefined. ( null being a topic of controversy). The general consensus is that null is an explicit value to tell that there is no value. In the example below, we try to pass null as an argument.

const list = [ 'luke', 'leia', 'darth vader' ];
filterEvil(list, null); // [ 'luke', 'leia', 'darth vader' ]

The filterEvil function will not substitute evil with a default value when supplied with null or any falsy value.

The filterEvil function will substitute if and only if evil is undefined. Now you are in luck, as Javascript will automatically use undefined if you do not explicitly pass an argument:

const list = [ 'luke', 'leia', 'darth vader' ];
filterEvil(list); // [ 'luke', 'leia' ]

This is something to keep in mind when working on projects which rely heavily on null.* (Although, I worry a lot about the developers who use null/undefined interchangeably)*

2. Evaluated Left to Right

The default parameters are evaluated from left to right. This is indeed confusing but a very powerful feature. Let us look at an example.


function findEvil(array, evil = 'darth vader', respect = 'Bad ' + evil) {
  if (array.find(item => item === evil)) {
     return respect;
  }
}

findEvil(list); // Bad darth vader;

findEvil(list, 'luke'); // Bad luke;

As you can see, we can reuse a param on the left as a default param for something on the right. Note that respect will get the evil param with the default check applied.

3. Calling a function

You can also call a function and use the value returned as a default parameter. In short this lets you call a regular function and compute the default parameter on the fly.

function whoIsEvilNow() {
  if (time > 2014) {
    return 'J. J. Abrams'
  }
  return 'darth vader';
}


function findEvil(array, evil = whoIsEvilNow()) {
  return array.find(item => item === evil);
}

4. Evaluated at call time

Now this feature is what confuses me the most. Let us look at an example. Confusing but a very powerful feature. Let us look at an example.

function filterEvil(array = [], evil = 'darth vader') {
  return array.filter(item => item === evil)
}

Each time you call an array without an argument, a new instance of an empty array is created.

Each time you call filterEvil without an argument, a new instance of an empty array is created. Now, this might become a problem if you are into into selectors and memoization. This behaviour can easily fool your dependant logic thinking something changed (I am talking to you React). For example, if you use reselect in your react project, your component can update unnecessarily as react will re-render with each new instance of the empty array.

Here are some cool tricks:

Required Param Check: You can use default params to enforce a required parameter. In the example below, we are enforcing evil as a required prop.

const isRequired = () => { throw new Error('param is required'); };

function filterEvil(array, evil = isRequired()) {
  return array.filter(item => item !== evil);   
}

Destructured Default Params: You can also use default params in a destructed expression.

function firstItem([first, second] = ['luke', 'skywalker']) {
  return first;
}

function findName({ name } = { name : 'darth' }) {
  return name;
}

I hope this post helped you in understanding default parameters.

Reach out to me on Twitter @kushan2020.

DEV Community: Kushan Joshi

How I learned to Stop Looping and Love the Iterator

The Problem with for loop

Functional Alternatives

The Iterable Approach

What is a protocol anyway?

Introducing iterables

What is Symbol and Symbol.iterator?

How do I implement the iteration protocol for my custom objects?

What is the difference between iterable & iterator ?

What do I get out of this complicated protocol?

Summary

Javascript Underdogs: Part 1 - The WeakMap

Why you would need something Weak

Caching the Area

Great! We made some serious performance improvements.

What about WeakMap?

How does it forget things?

What happens if we lose the key

WeakMap Takeaways

9 Promising Promise Tips

1. You can return a Promise inside a .then

2. You create a new Promise everytime you do .then

3. A Promise is resolved/rejected for EVERYONE

4. Promise Constructor is not the solution

5. Use Promise.resolve

6.Use Promise.reject

7. Use Promise.all

8. Do not fear the rejection OR

Do not append redundant .catch after every .then

9. Avoid the .then hell

One life saving Javascript Tip

Always Exit Early !

A toddlers guide to memory leaks in Javascript

Oh my fancy functional programming

Memory Leaks ….

Alright, but what about Memory Leaks??

Memory Leaks

Give me some real life leakages

Understanding Default Parameters in Javascript

Javascript before default parameters

Javascript after default parameters

1. Distinction between null and undefined.

2. Evaluated Left to Right

3. Calling a function

4. Evaluated at call time

Here are some cool tricks:

The Problem with `for loop`

What is the difference between `iterable` & `iterator` ?

Do not append redundant `.catch` after every .then