Case 1. Simple if / else if / else blocks

if (mode === "A") {
  return { isDisabled: true };
} else if (mode === "B") {
  return { isDisabled: true };
} else {
  return { isDisabled: false };
}

This is a common pattern that we see in applications. However, it is ripe for future spaghetti like updates. Let us see how we can tame it.

Option 1. Lose the else

We will try removing the else keyword. It is in fact, redundant.

if (mode === "A") {
  return { isDisabled: true };
}
if (mode === "B") {
  return { isDisabled: true };
} 
return { isDisabled: false };

Option 2. Use a switch statement

The previous solution…

TypeScript provides a certain comfort that nowhere will your functions or components be invoked with the wrong input, your code is always checked statically as you write. However, most applications have some kind of server-side API that drives its state; at this point, TypeScript is not in play because the code that executes in your browser only contains plain JavaScript. When it comes to handling external data, always follow the axiom:

Trust but verify

In a recently completed a project, we noticed that most of our unit tests were not testing for negative conditions that involve undefined/null/empty values. The reason…

A few years ago, I started seeking simplicity and minimalism in everything. It reflected in my work too. So, when the TypeScript “hype” started, I simply shut myself out to it because adopting it seemed like a huge undertaking and it would disturb my zen. It would take a year of trying it out in a large enterprise application before it all changes. In hindsight, there are a few things that helped my team and I to adopt TypeScript.

1. Understanding what TypeScript really is

If you go through TypeScript handbook it is unclear where JavaScript ends and TypeScript begins. …

Fresh grads, recruits from coding camps, ex-Java/Perl/Ruby/Python coders tend to write in an imperative style. There is nothing wrong with it, I was in the same boat. I remember sometimes certain data transformation functions were so nested with conditional logic strewn through out, I couldn’t reason my own code after a few months. Debugging was a nightmare. Then I read up on functional programming and it changed the way I wrote code.

An example

We’re going to write a simple function that takes in an array of numbers and return anything less than 7 as a new array of formatted strings. …

There are no ideal software projects. Challenges are plenty, caused by technology and people. But I believe that if you provide a fantastic developer experience, you end up creating a higher quality product. Bugs are a manifestation of lack of knowledge, confusion, short cuts, bad practices and over dependence on horizontal organizations/packages. Here are a few factors that can improve a frontend developer’s day in the life. While these factors may seem like common sense, we still see these compromised, especially as a project ages.

1. Learning curve

Search online about using nested ternaries and you will see varying degrees of approvals. IMO, nested ternary expressions are compact and a better alternative to using if/else. Let us take a fictitious large if else condition:

const pageName = (index, state) => {
  if (index === 0 && state === "active") {
    return "Intro";
  } else if (index === 0 && state === "inactive") {
    return "Intro - Inactive";
  } else if (index === 1) {
    return "Contents";
  } else {
    return"Extra";
  };
}

Ternary expressions can be much more compact and still maintain the same clarity:

const pageName =…

In my experience, a lot of developers write the reduce function with a mental model of its semantics. It is approached as a boilerplate-y function. A reduce function kinda gets booted like this in the code:

data.reduce((acc, item) => {
 // do the thing;
 // return something
}, initialValue);

All good but what could really help is to split this into two parts:

1. The reducer function
2. The reduction itself

The reducer is simply a combiner function. It takes two inputs and returns a new value. In the context of a reduction, it takes an existing value (the accumulator) and value…

useState()

useState() manages a single state variable, it is the most atomic state management hook in React.

const [counter, setCounter] = useState(0);

It returns the state variable that you can bind your components or logic to. It also provides a setter function that you can update the state’s value with. Modifying the state variable directly has no effect on the data binding. useState can also manage arrays and objects. Even nested ones. One thing you have to make sure while managing arrays and objects via useState is to enforce immutability. Which means that your setXXX function should always use a fresh…