How i structure my projects in react + typescript

Maintaining a scalable and easy-to-understand codebase starts with a solid project structure. When working with React + TypeScript, a well-thought-out folder and file organization can make collaboration smoother and development faster.

Let me show you how I usually organize my projects and the reasoning behind each decision.

📁 Base folder structure

Here's a basic overview of how I structure most of my React + TypeScript apps:

src/
│
├── assets/         # Static files (images, icons, fonts)
├── components/     # Reusable UI components
├── features/       # Feature-based folders (each one contains logic + UI)
├── hooks/          # Custom hooks
├── pages/          # Route-level components (if using React Router or Next.js)
├── services/       # API calls and business logic
├── types/          # Global TypeScript types and interfaces
├── utils/          # Utility functions and helpers
├── constants/      # App-wide constants (enums, config, etc.)
├── store/          # Redux, Zustand or any state management logic
└── index.tsx       # App entry point

🧩 Features folder

Instead of a strict separation by type (e.g., all components in one place), I prefer a feature-based approach:

features/
└── auth/
    ├── components/
    ├── hooks/
    ├── services/
    ├── AuthPage.tsx
    └── authSlice.ts

This way, everything related to the auth feature is grouped together. It improves discoverability and reduces coupling between unrelated parts of the app.

📦 Components vs features

Use components/ for truly reusable and dumb components (e.g., Button, Modal, Input). These should not depend on any app-specific logic.

Use features/ for domain-specific components that are tied to business logic.

🛠️ Services

Place your API calls, external integrations, or domain logic here:

// services/userService.ts
export const getUserById = async (id: string) => {
  const response = await fetch(`/api/users/${id}`);
  return response.json();
};

Group them by domain when needed (e.g., authService, userService, reportService).

✍️ Types and interfaces

Define global types in types/ and feature-specific ones inside the relevant feature folder:

// types/user.ts
export interface User {
  id: string;
  name: string;
  email: string;
}

Or:

// features/reports/types.ts
export interface Report {
  id: string;
  createdAt: string;
  data: ReportData;
}

⚙️ State management (OPTIONAL)

If you're using a state management library like Redux or Zustand, place slices/stores under store/:

store/
├── index.ts         # Combine reducers or stores
└── userSlice.ts

Or colocate slices within the features/ folder if they’re tightly scoped to that feature.

💡 Bonus tips

• ✅ Use barrel files (index.ts) to simplify imports.
• ✅ Name files using PascalCase for components (LoginPage.tsx) and camelCase for utils (formatDate.ts).
• ✅ Keep styles close to the component (Component.module.css or styled-components).
• ✅ Prefer co-location: keep files that change together near each other.

✅ Summary

📌 Conclusion

There’s no “perfect” folder structure, but choosing one that prioritizes clarity, scalability, and collaboration makes a huge difference. Feature-based organization helps keep related code together, and TypeScript makes it easier to maintain consistency across your project.