4 Alarming Mistakes Which Will Doom Your React Applications

If you want to doom your react applications with a terribly managed, bug infested, time sucking blackhole of a codebase, then do the four things outlined below… say goodbye to any new features and profits, as developer time is spent fixing mistakes.

Photo by Caleb Woods on Unsplash

Nesting Components Inside Components

Do not nest components inside components using variables or functions to render JSX which is conditional, or requires interpolation. React is made with components for composition. When something is complex enough that an inline JSX ternary is not sufficient and extra processing and complex conditionals require it to be extracted into its own function, just make a new component.

Don’t put JSX inside variables or functions for conditional rendering. Use a component with a descriptive name.

Use <Components /> instead of render functions (e.g. renderComponent). Don’t put JSX inside variables or functions for conditional rendering. Use a component with a descriptive name. e.g:

renderBottomFooterConditions() { ... ❌

<MyComponentBottomFooterConditions ✅

Splitting each component into smaller units allows conditions and interpolations to be split across files reducing the size and complexity of your components.

Playing with Nested Objects

Stop passing nested objects through components props when you are not using a TypeSystem. When you are using a TypeSystem, this can be easier to neglect, but doing this still couples a specific object structure to a component.

Flatten your component props

There are some cases where you would want to pass an object as a component property e.g. “you have a common set of data processing logic which needs to happen in multiple places across your application”, but that case is rare, and usually has to do with lists, see my article about this.

If you have a component which renders an Image from your server and calculates the aspect ratio to fit a container, and you need to pass two properties; authToken, imageUrl, you should flatten the properties:

<AuthImage
  authToken={...} ✅
  imageUrl={...} ✅

You should not pass the whole object to the component, binding the component to that object structure:

<AuthImage
  imageStuff={{ authToken: ..., imageUrl: ... }} ❌

Working with objects is more complex and error prone than single value variables; booleans, numbers, strings.

Not Using Descriptive Naming

This is not Twitter, you don’t have a character count limit… stop giving your variable and functions short generic names, which leave other developers clueless when reading your code. Files, variables and functions should have expressive and descriptive names. Your code is meant to be understood by others. e.g.

let messageForTheWarningBanner = messages?.message_for_banner ✅

let message = messages?.message_for_banner ❌

The first variable immediately tells us more about the information it contains.

When deconstructing objects and arrays in JavaScript, you should re-assign variable names to match the current context. e.g.

const { name: companyName } = useSelector(
     state => getOrganisation(state)
); 
const { email: currentEmail } = useSelector(
     state => getUser(state)
);

Code is for humans not computers

Not Explaining ‘Why’

Please… comment your code.

Comments drastically increase the robustness of your project, not commenting code is like selling a ‘build it yourself’ bookshelf with no instructions. If you do not know how to comment code, here is the simple secret behind it… 🥁🥁🥁

Explain ‘Why’ not ’How’

Comments are used to explain the ‘why’ behind the code. The ‘how’ can be inferred from looking at the code. Talk about the reasons behind your choices for writing that portion of code. Here is a comment for a single variable, in a real-world application:

/** 
* Used so the rebrand alert does not appear multiple times, 
* as if the user exits the app, this will trigger new user data 
* to be fetched, which will trigger new organisation data to be 
* fetched, which will lead to multiple FETCH_ORGANISATION_RESPONSE 
* and multiple instances of this generator function waiting at 
* call(waitUntilStack.... 
*/ 
let isRebrandAlertShowed = false;

The ‘how’ can be inferred from the code… the ‘why’ is forever lost…

Apply these principles to your application to win back stability in your codebase and harness the power of clean code to build features and impact larger numbers of people.