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. …
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.
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 };
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.
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.
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.
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:
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() 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…
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:
Frontend Architect, San Jose, CA