Clean Code - Avoid Deeply Nested Code
Learn why avoiding deeply nested code is a key clean code practice in Coding. Discover simple tips like returning early and using guard clauses to make your code easier to read, maintain, and debug. Clean up your code with this easy-to-follow guide!
TypeScript Type Assertion 'as': Mastering Type Safety in Your Codebase
Explore the power of TypeScript's type assertion to ensure robust type safety within your projects. Enhance code readability and maintainability effortlessly.
How not to name your Types
Naming conventions, also known as code nomenclature or coding conventions, are important in software development for several reasons: Readability, Maintainability, Code Reusability, Consistency, Documentations, and Scalability. Here we shall discuss some naming conventions I follow and recommend so that the next time you are writing new types it’s easier for you to name them.
Format numbers to Ordinals
Ordinal suffix number format is a way of writing numbers that indicates their position in a sequence, such as first, second, third, etc. This format is commonly used in writing dates, ranks, and other similar contexts.
Prefetching React Lazy
How to prefetch React Lazy components or pages so that your page transitions are as smooth and fast as possible. This blog is in continuation of my earlier blog about Energetic React Lazy, where I discussed about code splitting and how you can use React Lazy to make your app lighter and faster.
The Energetic React Lazy
You might have heard about React lazy and suspense before, but might never have felt the energies ⚡️ it has, I don’t know why is it called lazy why not energy or maybe flash, I guess it’s called as lazy since it lazily loads something 🤔.
The missing chapter of Code Reviews
Code Reviews have been an integral part of Software Development Lifecycle, but lately this topic has been missing from our engineering books. This document covers some aspects of why we review code, how we should review code etc.
Data Driven React UI Components
Component structures are very unopinionated in terms of how they receive data - is it via props, or do they handle their own data/business logic? How your components are designed largely decide the fate of our application, onto how people are going to reuse the components, are they actually reusable or not, how much of a refactor does a component require before plugging in, how easier is it to plug the component and just use it.