5 Mistakes I Avoided While Building a React and TypeScript Application

Mehrab Gholamsamani — Sat, 28 Feb 2026 11:35:16 +0000

When building React applications, most problems do not appear on day one.

They show up weeks later.

Components become harder to understand.
State spreads everywhere.
Performance slowly declines.

I recently built a production ready React and TypeScript application, and instead of focusing only on features, I focused on avoiding common structural mistakes.

Here are five mistakes I intentionally avoided and why they matter.

1. Putting API Calls Directly Inside Components

It is very common to see something like this inside a component:

You mount the component.
You call fetch.
You set state.

It works.

Until five components need similar logic.

Instead, I created a dedicated API layer.

Each endpoint had its own typed function.
All requests were centralized.
Error handling lived in one place.

This gave me three advantages:

Cleaner components
Stronger type safety
Easier refactoring

Components became responsible for UI, not networking.

That separation is small at first but huge later.

2. Overusing Global State Too Early

It is tempting to introduce global state management immediately.

But global state spreads like ink in water.

I followed a simple rule.

Keep state local unless multiple distant components truly depend on it.

Local state first.
Lift state only when needed.
Use context only for authentication or truly global concerns.

Overengineering state early is like installing traffic lights in your driveway. It solves a problem you do not have.

Complexity should be earned, not assumed.

3. Ignoring Type Safety in API Responses

When integrating REST APIs, I defined strict interfaces for every response.

Instead of treating responses as any, I wrote explicit types.

This prevented:

Accessing properties that do not exist
Silent runtime failures
Accidental shape mismatches

TypeScript caught issues before they reached production.

Strong typing is not about writing more code.
It is about reducing uncertainty.

4. Allowing Unnecessary Re Renders

As data grew, performance issues started appearing.

React re renders are cheap at first.
They become expensive when multiplied.

To prevent unnecessary work, I used:

React memo for stable components
useMemo for expensive derived data
useCallback when passing functions to child components

I also paid attention to dependency arrays carefully.

Performance optimization is not premature optimization when you are dealing with dynamic dashboards.

It is maintenance prevention.

5. Letting Components Grow Unbounded

Large components are one of the fastest ways to lose clarity.

If a component:

Fetches data
Manages complex state
Renders layout
Handles business logic

It becomes difficult to reason about.

I split responsibilities into:

Container components
Presentational components
Reusable UI elements

Smaller pieces are easier to test, debug, and extend.

It also makes onboarding easier for other developers.

What I Learned

Scalability is less about tools and more about discipline.

React and TypeScript provide excellent foundations.

But structure, separation of concerns, and clear decision making are what keep a project maintainable.

You do not feel the benefit immediately.

You feel it three months later when adding a new feature does not break everything.

That is when you realize architecture matters.

Final Thought

Building front end applications is not just about getting features done.

It is about making sure future changes are predictable.

If you are working with React and TypeScript, focus early on:

Clear separation of concerns
Strong type definitions
Controlled state growth
Intentional performance decisions

Your future self will thank you.

At the end, add something natural like:

You can explore the full project and other work on my portfolio here: