Skip to content

React Clean Code: 5 Bad Habits to Avoid

Posted on:January 24, 2026 at 10:00 AM

Hello, Fellow Coders! šŸ‘‹

Have you ever opened an old codebase (or a friend’s), and thought to yourself: ā€œWhat in the world is this mess?ā€ šŸ˜µā€šŸ’«

Building a React app that ā€œworksā€ is easy. But building one that is ā€œreadableā€ and ā€œmaintainableā€ is an art. Often, especially when we’re starting out, we fall into traps that turn our code into spaghetti.

Today, I want to share 5 bad habits you need to ditch immediately if you want to level up to Senior. Think of this as a casual mentorship session over coffee. ā˜•

Let’s dive in!

1. The God Component

This is the most common sin. A single Dashboard.jsx file with 500 lines of code. It has data fetching logic, a table, a modal, an edit form, all crammed into one place.

The Problem: Hard to read, hard to test, and if you want to fix one feature, you’re terrified of breaking another.

The Solution: Break it up! Principle: Single Responsibility.

// āŒ DON'T: One giant component
const Dashboard = () => {
  // ... 500 lines of logic ...
  return (
    <div>
      <Header />
      <div className="sidebar">...</div>
      <div className="content">
        <table>...</table>
        <form>...</form>
      </div>
    </div>
  );
};

// āœ… DO: Split into smaller components
const Dashboard = () => {
  return (
    <Layout>
      <Sidebar />
      <UserTable />
      <EditUserForm />
    </Layout>
  );
};

See? Much easier on the eyes.


2. Prop Drilling (Passing the Baton)

You have data in your App component, but the one who needs it is the GreatGrandChild. So you pass the props through 5 layers of components that don’t actually need that data.

The Problem: Middle components become ā€œpollutedā€ accepting props they don’t use. If the structure changes, it’s a nightmare to fix.

The Solution: Use Composition (children prop) or Context API.

// āŒ DON'T: Passing props through components that don't care
<Dashboard user={user} />
// Dashboard only accepts 'user' to pass to Navbar
<Navbar user={user} />
// Navbar only accepts 'user' to pass to Avatar
<Avatar user={user} />

// āœ… DO: Composition
<Dashboard>
  <Navbar>
    <Avatar user={user} />
  </Navbar>
</Dashboard>

3. Complex Logic inside JSX

JSX is for displaying UI, not for heavy thinking. Don’t put complex JavaScript logic inside the curly braces {}.

The Problem: Hard to read. Your JSX becomes cluttered with nested ternary operators ? :.

The Solution: Extract logic into variables or small functions above the return.

// āŒ DON'T: Nested ternary operators that induce headaches
return (
  <div>
    {user && user.role === 'admin' ? (
      <AdminPanel />
    ) : user && user.isActive ? (
      <UserDashboard />
    ) : (
      <GuestView />
    )}
  </div>
);

// āœ… DO: Store in a variable for clarity
const renderContent = () => {
  if (!user) return <GuestView />;
  if (user.role === 'admin') return <AdminPanel />;
  return <UserDashboard />;
};

return <div>{renderContent()}</div>;

4. Hardcoded Values (Magic Numbers)

Ever seen code like this? if (status === 2) { ... }

What is 2? Success? Pending? Failed? Only God and you (at the moment of writing) know. A week later, even you will forget.

The Problem: If the status changes, you have to hunt down the number 2 across the entire project.

The Solution: Use Constants or Enums.

// āŒ DON'T: Use magic numbers/strings
if (role === 'role_1') { ... }

// āœ… DO: Define constants
const ROLES = {
  ADMIN: 'role_1',
  USER: 'role_2'
};

if (role === ROLES.ADMIN) { ... }

5. Ambiguous or Verbose Variable Names

Variable names are documentation. Don’t be stingy: const d = ... (is d data? date? dog?). Don’t be verbose: const dataFetchedFromServerToDisplayInTable = ... (too long!).

The Problem: Confuses the reader.

The Solution: Be clear and concise.

// āŒ DON'T
const [flag, setFlag] = useState(false);
const h = () => { ... }

// āœ… DO
const [isModalOpen, setIsModalOpen] = useState(false);
const handleCloseModal = () => { ... }

Conclusion

Clean code isn’t just for show. It’s a form of self-love (and love for your team) for the future.

Start small. Break up components, name variables correctly, and don’t be lazy to refactor. Remember, the code you write today is the code you maintain tomorrow. Be kind to your future self.

Happy Coding! 🧹✨