Damian Cipolat

Posted on Mar 2, 2020 • Edited on Mar 5, 2020

Avoid use IF on our JS scripts

#javascript #if #patterns

Well, I write this article because lately I was dealing with source code in js that had an excessive amount of if statement,
at levels that I had never seen. That is why I think it is very important to share these simple techniques that will help us to write code without having to think about the "if" when deciding.

I am going to explain 6 ways on how to do this. The idea of this is not to enter into paranoia of never using IF, it is to open the head to new ways of thinking about our decisions in JS.

1) Ternary operator:

We are talking about this "condition ? expr1 : expr2", very easy.

Example 1:

Code with IF:

function saveCustomer(customer) {
  if (isCustomerValid(customer)) {
    database.save(customer)
  } else {
    alert('customer is invalid')
  }
}

Refactored code:

function saveCustomer(customer) {
  return isCustomerValid(customer)
    ? database.save(customer)
    : alert('customer is invalid')
}

ES6 style:

const saveCustomer = customer =>isCustomerValid(customer)?database.save(customer):alert('customer is invalid')

Example 2:

Code with IF:

function customerValidation(customer) {
  if (!customer.email) {
    return error('email is require')
  } else if (!customer.login) {
    return error('login is required')
  } else if (!customer.name) {
    return error('name is required')
  } else {
    return customer
  }
}

Refactored code:

// ES6 style custom formatted ternary magic
const customerValidation = customer =>
  !customer.email   ? error('email is required')
  : !customer.login ? error('login is required')
  : !customer.name  ? error('name is required')
                    : customer

Example 3:

Code with IF:

function getEventTarget(evt) {
    if (!evt) {
        evt = window.event;
    }
    if (!evt) {
        return;
    }
    const target;
    if (evt.target) {
        target = evt.target;
    } else {
        target = evt.srcElement;
    }
    return target;
}

Refactored code:

function getEventTarget(evt) {
  evt = evt || window.event;
  return evt && (evt.target || evt.srcElement);
}

⮬ back to top

2) Short circuit:

It is a technique that uses the AND and OR operators to evaluate expressions.

https://codeburst.io/javascript-short-circuit-conditionals-bbc13ac3e9eb

true || true;
// true
true || false;
// true
false || false;
// false

Example 1:

Code with IF:

const isOnline = true;
const makeReservation= ()=>{};
const user = {
    name:'Damian',
    age:32,
    dni:33295000
};

if (isOnline){
    makeReservation(user);
}

Refactored code:

const isOnline = true;
const makeReservation= ()=>{};
const user = {
    name:'Damian',
    age:32,
    dni:33295000
};

//Apply the short circuit to avoid the if.
isOnline&&makeReservation(user);

Example 2:

Code with IF:

const active = true;
const loan = {
    uuid:123456,
    ammount:10,
    requestedBy:'rick'
};

const sendMoney = ()=>{};

if (active&&loan){
    sendMoney();
}

Refactored code:


const active = true;
const loan = {
    uuid:123456,
    ammount:10,
    requestedBy:'rick'
};

const sendMoney = ()=>{};

//Apply short circuit in this case, the loan is evaluated true because !=undefined
active && loan && sendMoney();

⮬ back to top

3) Function delegation:

This technique mix the short circuit and separation code block with functions.

Example 1:

Code with IF:

function itemDropped(item, location) {
    if (!item) {
        return false;
    } else if (outOfBounds(location) {
        var error = outOfBounds;
        server.notify(item, error);
        items.resetAll();
        return false;
    } else {
        animateCanvas();
        server.notify(item, location);
        return true;
    }
}

Refactored code:

function itemDropped(item, location) {
    const dropOut = function() {
        server.notify(item, outOfBounds);
        items.resetAll();
        return false;
    }

    const dropIn = function() {
        server.notify(item, location);
        animateCanvas();
        return true;
    }

    return !!item && (outOfBounds(location) ? dropOut() : dropIn());
}

⮬ back to top

4) Non branching strategy:

This technique try to avoid the use of switch statemente. The idea is to create a map with keys/values and using a function
to access the value of the key passed as parameter.

The idea came from this link: https://medium.com/chrisburgin/rewriting-javascript-replacing-the-switch-statement-cfff707cf045

Example 1:

Code with SWITCH:

switch(breed){
    case 'border':
        return 'Border Collies are good boys and girls.';
        break;  
    case 'pitbull':
        return 'Pit Bulls are good boys and girls.';
        break;  
    case 'german':
        return 'German Shepherds are good boys and girls.';
        break;
    default:
        return 'Im default'

}

Refactored code:


const dogSwitch = (breed) =>({
  "border": "Border Collies are good boys and girls.",
  "pitbull": "Pit Bulls are good boys and girls.",
  "german": "German Shepherds are good boys and girls.",  
})[breed]||'Im the default';


dogSwitch("border xxx")

⮬ back to top

5) Functions as Data:

We know that in JS the function are first class, so using it we can split the code into a function objects.

Example 1:

Code with IF:


const calc = {
    run: function(op, n1, n2) {
        const result;
        if (op == "add") {
            result = n1 + n2;
        } else if (op == "sub" ) {
            result = n1 - n2;
        } else if (op == "mult" ) {
            result = n1 * n2;
        } else if (op == "div" ) {
            result = n1 / n2;
        }
        return result;
    }
}

calc.run("sub", 5, 3); //2

Refactored code:

const calc = {
    add : function(a,b) {
        return a + b;
    },
    sub : function(a,b) {
        return a - b;
    },
    mult : function(a,b) {
        return a * b;
    },
    div : function(a,b) {
        return a / b;
    },
    run: function(fn, a, b) {
        return fn && fn(a,b);
    }
}

calc.run(calc.mult, 7, 4); //28

⮬ back to top

5) Polymorphism:

Polymorphism is the ability of an object to take on many forms. The most common use of polymorphism in OOP occurs when a parent class reference is used to refer to a child class object.

Example 1:

Code with IF:

const bob = {
  name:'Bob',
  salary:1000,
  job_type:'DEVELOPER'
};

const mary = {
  name:'Mary',
  salary:1000,
  job_type:'QA'
};

const calc = (person) =>{

    if (people.job_type==='DEVELOPER')
        return person.salary+9000*0.10;

    if (people.job_type==='QA')
        return person.salary+1000*0.60;
}

console.log('Salary',calc(bob));
console.log('Salary',calc(mary));

Refactored code:

//Create function to different behaviour, same parameter call.
const qaSalary  = (base) => base+9000*0.10;
const devSalary = (base) => base+1000*0.60;

//Add function to the object.
const bob = {
  name:'Bob',
  salary:1000,
  job_type:'DEVELOPER',
  calc: devSalary
};

const mary = {
  name:'Mary',
  salary:1000,
  job_type:'QA',
  calc: qaSalary
};

//Same call.
console.log('Salary',bob.calc(bob.salary));
console.log('Salary',mary.calc(mary.salary));

⮬ back to top

Readings:

A list of interesting links about this same topic.

Visit my github for more projects!!
https://github.com/damiancipolat?tab=repositories

Latest comments (47)

Jakub T. Jankiewicz • Jul 18 '20

Most of the suggestions will just make your code a nightmare to maintain. This is the opposite of clean code. If someone want better code he should not use tricks like that. Good luck reading your code that was written few years ago, I only hope that it will not be someone that new into programming.

Joe Attardi • Mar 10 '20

Nested ternaries? Yuck.

Maxime Moreau • Mar 9 '20

Hi, thank you for writting. As a lot of people say, sometimes is not readable, always think readability and the most important, think for the others, junior devs and so one :)

Have a nice day!

Rohit Prasad • Mar 8 '20

ESLint discourages the use of nested ternary conditions.

Damian Cipolat • Mar 8 '20

It's the problem you are letting the lint tell you how you have to program. eslint can be configured by activating and deactivating rules to suit each one.

Ben Calder • Mar 8 '20

Q. Who wrote the linter rules?
A. People with enough experience to know that nested ternaries are really difficult for a human to parse quickly and therefore make code difficult to work with.

Malte Büchmann • Mar 5 '20

Very nice article. But I think I found one catch:

The rewrite in the second example for ternary operators makes the code very unreadable. The cumbersome part of this example are the else statements. If you use guard clauses if statements, the code becomes much more readable and concise:

function customerValidation(customer) {
  if (!customer.email) {
    return error('email is require');
  } 
  if (!customer.login) {
    return error('login is required');
  }
  if (!customer.name) {
    return error('name is required');
  }
  return customer;
}

In this case, you can even remove the curly braces:

function customerValidation(customer) {
  if (!customer.email)
    return error('email is require');  
  if (!customer.login)
    return error('login is required');
  if (!customer.name)
    return error('name is required');

  return customer;
}

Now both versions are much more readable and the reader can understand the intent of the written code much better: catch errors and return them.

Damian Cipolat • Mar 5 '20

thanks for comment!

Wilfredo Pérez • Mar 5 '20

Hey Damian the last example is not working.

//Create function to different behaviour, same parameter call.
const qaSalary  = (base) => base+9000*0.10;
const devSalary = (base) => base+1000*0.60;

//Add function to the object.
const bob = {
  name:'Bob',
  salary:1000,
  job_type:'DEVELOPER',
  calc: devSalary
};

const mary = {
  name:'Mary',
  salary:1000,
  job_type:'QA',
  calc: qaSalary
};

//Same call.
console.log('Salary',bob.calc());
console.log('Salary',mary.calc());

the output is:

Salary NaN
Salary NaN

Damian Cipolat • Mar 5 '20

:o :O yes that true, I will fix it. thanks for tell me.

Damian Cipolat • Mar 4 '20

Maybe add a señority level indicator before star reading the article.

Raul • Mar 4 '20 • Edited

The article is nice, it gives some cool alternatives that not everyone might know about, a handful of which we use at work.

As others said, tho, some are harder to read.

A little side note about #4 and #5: it would be better to re-use the object and not to create it every time a function is called (eg: creating it inside array.map(), etc), it slows down your code a lot!

I'm saying this because it might not be obvious and also because I've had to refactor some code that was doing the exact same thing after I got hired 😊

A better approach would be to do something like this instead:

const createDogSwitcher = () =>{
  const objectSwitch = {
    border: 'Border Collies are good boys and girls.',
    pitbull: 'Pit Bulls are good boys and girls.',
    german: 'German Shepherds are good boys and girls.',  
  }

  const defaultString = 'Im the default.'

  return (breed) => objectSwitch[breed] || defaultString
}

const dogSwitch = createDogSwitcher()

dogSwitch('border xxx')

// Now use `dogSwitch` inside `map()`

If you want even better performance out of this, you can use a Map() instead of an object 🖖🏼

Edit: I think you have two #5s 🤔

Damian Cipolat • Mar 4 '20

thanks for comments! the idea was make an arrow function that return an object. I had thought about this option too, it is more semantic but much more code. It is in each developer as you feel more comfortable.

kk • Mar 4 '20

thanks, you're open my world :DDD

Nicolás Mariano Obregón • Mar 3 '20 • Edited

Hi @damxipo !
I'm a ternary fan, but as many said, those nested ternaries are harder to read than the ifs.
I really liked the switch alternative, I'm going to implement it right now.

Please, pleeease, change those vars to let/const :)

Thanks Damian, really good article! Keep it coming