React Project Structure for Modularity and Reusability

React Project Structure for Modularity and Reusability

Splitting a React project into components, core, features, and shared directories, each with a defined dependency direction.

Takahiro Iwasa
2 min read

Directory Structure

  • components
    • Contains simple and abstract common components.
    • These components are used across the project and can be considered application-wide parts.
  • core
    • Holds the application-core functionality with application-wide utilities.
    • Accessible from features and shared but must not reference features.
  • features
    • Each feature module resides here.
    • These modules may reference components, core or shared but must remain isolated from the rest of the application to maintain modularity.
  • shared
    • Contains shared utilities and components.
    • Accessible from features but must not reference them.

Terminal window
src/
├── assets/
├── components/
├── Elements/
├── Forms/
├── Layouts/
├── Modals/
├── Pages/
├── Errors/
├── AccessDeniedPage.tsx
├── NotAuthenticatedPage.tsx
├── SystemErrorPage.tsx
├── ...
├── ErrorBoundary.tsx
├── core/
├── api/
├── interceptors/
├── config/
├── hooks/
├── loaders/
├── models/
├── api/
├── stores/
├── utils/
├── features/
├── auth/
├── .../
├── shared/

Conclusion

Splitting a React project into components, core, features, and shared directories, each with a defined dependency direction, keeps UI primitives, application-wide logic, and feature code from bleeding into each other. The extra components layer is what distinguishes this structure from a typical core/features/shared split: it separates application-wide UI primitives (buttons, layouts, modals) from shared, which is meant for reusable non-visual utilities and logic. That distinction matters in practice — as the project grows, it keeps a question like “should this button variant go in components or shared” from becoming ambiguous, since the answer is always determined by whether it’s a UI element or not, rather than by how many features happen to use it.

About the author

Takahiro Iwasa

Takahiro Iwasa

Software Developer

This blog shares technical notes from hands-on projects—architecture, implementation, and AWS service integrations.