A good strategy can eliminate several classes of bugs

Image for post
Image for post
Image by Annette Meyer from Pixabay

According to the paper The Mythical Man Month by Frederick Brooks, developers are optimists and I agree. Most of us tend to focus on the happy path of a feature, working within the warmth of hot-reloads, VSCode and Chrome dev tools, trusting the APIs to always work and assuming that if anything is wrong, QA will catch it. If only.

In this article, I’ll try to present practical steps we can take to eliminate certain classes of bugs from large JavaScript applications. …


Back to basics — Writing conditionals

Image for post
Image for post
Image by Steve Buissinne from Pixabay

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…


Use the “unknown” type

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…


For React devs, it is not hard as you think

Image for post
Image for post
Source: Wikipedia

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. …


Quality of an abstraction depends on the quality of its units

Image for post
Image for post
Image by Edi Nugraha from Pixabay

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. …


Happy and focused developers write better code

Image for post
Image for post

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


You don’t have to. Leave it to Prettier.

Image for post
Image for post
Image Source

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 =…

Forming the correct mental picture of an important tool

Image for post
Image for post
Image source : https://pixabay.com/users/publicdomainpictures-14/

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() vs useReducer()

Image for post
Image for post
Image adapted from Pixabay

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…


Using data transformers between Forms and API

Image for post
Image for post
Image by René Beck from Pixabay

In a previous article, I detailed out how to wrangle large Formik forms using sub forms and composing them within a larger form. In typical enterprise applications, a large form’s goal is to capture user input that will be sent to a server via REST or GraphQL. The biggest challenge we face is dealing with nested API data that doesn’t bend well within a flat form. A typical use case is like this:

  • API returns a business object and hydrates the form with it.
  • User edits this and submits the values.
  • Form submit action performs an API call directly or…

Rajesh Naroth

Frontend Architect, San Jose, CA

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store