How many types of frontend project structures are there?

Structuring a Frontend project is very important for developing an efficient and easy-to-maintain application. Good structure makes the code easy to understand. and can expand features efficiently Especially when using Next.js and TypeScript in development. Here are several commonly used project structures:

1. Basic Structure

my-next-app/
├── public/              # Static files like images, fonts, etc.
├── src/                 # Source code
│   ├── components/      # Reusable components
│   ├── pages/           # Page components (Next.js routing)
│   ├── styles/          # CSS/SASS files
│   ├── hooks/           # Custom hooks
│   ├── contexts/        # Context API providers
│   ├── utils/           # Utility functions
│   ├── types/           # TypeScript types/interfaces
│   ├── services/        # API calls or services
│   ├── lib/             # Any additional libraries or helpers
│   └── config/          # Configuration files
├── .gitignore           # Git ignore file
├── next.config.js       # Next.js configuration
├── package.json         # npm/yarn package file
└── tsconfig.json        # TypeScript configuration

2. Atomic Design Structure

Atomic Design is a UI design concept that emphasizes separating components based on size and functionality. Can be divided into 5 levels: Atoms, Molecules, Organisms, Templates, and Pages

my-next-app/
├── public/                 # Static files
├── src/
│   ├── components/         # UI components
│   │   ├── atoms/          # Smallest elements like buttons, inputs
│   │   ├── molecules/      # Combinations of atoms (e.g., form groups)
│   │   ├── organisms/      # Complex UI components (e.g., header, footer)
│   │   ├── templates/      # Page templates with placeholders
│   │   └── pages/          # Page components
│   ├── pages/              # Next.js routing (can be left for dynamic routing)
│   ├── hooks/              # Custom hooks
│   ├── contexts/           # Context providers
│   ├── utils/              # Utility functions
│   ├── types/              # TypeScript interfaces/types
│   ├── services/           # API services
│   ├── lib/                # Additional libraries/helpers
│   └── config/             # Configurations
├── .gitignore
├── next.config.js
├── package.json
└── tsconfig.json

3. Feature-Based Structure

Feature-based structure is another way to make it easier to manage and expand new features. It's easy

my-next-app/
├── public/                 # Static files
├── src/
│   ├── features/           # Separate by features/modules
│   │   ├── featureA/
│   │   │   ├── components/ # Components specific to FeatureA
│   │   │   ├── pages/      # Pages related to FeatureA
│   │   │   ├── hooks/      # Hooks specific to FeatureA
│   │   │   ├── services/   # API calls related to FeatureA
│   │   │   └── utils/      # Utility functions for FeatureA
│   │   └── featureB/       # Another feature module
│   ├── shared/             # Shared resources across features
│   │   ├── components/     # Shared components
│   │   ├── hooks/          # Shared hooks
│   │   ├── contexts/       # Shared contexts
│   │   └── utils/          # Shared utilities
│   ├── styles/             # Global styles
│   └── config/             # Configuration files
├── .gitignore
├── next.config.js
├── package.json
└── tsconfig.json

4. Monorepo Structure with NX or Turborepo

This structure is project management with multiple projects or modules in one place. Suitable for large teams or projects that require clear separation of each part of development

my-next-monorepo/
├── apps/                   # Applications (Next.js, React, etc.)
│   ├── web/                # Next.js app
│   └── admin/              # Another Next.js app or admin panel
├── packages/               # Shared packages or libraries
│   ├── ui/                 # UI component library
│   ├── utils/              # Utility functions
│   ├── hooks/              # Custom hooks
│   └── services/           # API service packages
├── .gitignore
├── nx.json                 # NX configuration (if using NX)
├── turbo.json              # Turborepo configuration (if using Turborepo)
├── package.json
└── tsconfig.json

5. Layered Architecture Structure

Layered architecture design makes it easy to separate project functions

my-next-app/
├── public/                 # Static files
├── src/
│   ├── presentation/       # UI components, pages, and routing
│   │   ├── components/     # UI components
│   │   ├── pages/          # Next.js pages
│   │   └── routes/         # Custom routing logic
│   ├── domain/             # Business logic and entities
│   │   ├── entities/       # Domain entities
│   │   ├── useCases/       # Business use cases
│   │   └── repositories/   # Interfaces for data repositories
│   ├── infrastructure/     # Data access and external services
│   │   ├── api/            # API service implementations
│   │   ├── db/             # Database access
│   │   └── thirdParty/     # Third-party integrations
│   ├── shared/             # Shared utilities and configurations
│   │   ├── utils/          # Utility functions
│   │   └── config/         # Configuration files
│   └── styles/             # Global styles
├── .gitignore
├── next.config.js
├── package.json
└── tsconfig.json

6. Component-Driven Structure with Storybook

Using Storybook is a systematic test and development of separated UI components. Makes it easy to test component functionality

my-next-app/
├── public/                 # Static files
├── src/
│   ├── components/         # UI components
│   │   ├── Button/         # Button component
│   │   │   ├── Button.tsx
│   │   │   ├── Button.stories.tsx
│   │   │   └── Button.test.tsx
│   │   └── Input/          # Input component
│   ├── pages/              # Next.js pages
│   ├── hooks/              # Custom hooks
│   ├── utils/              # Utility functions
│   ├── styles/             # Global styles
│   └── config/             # Configuration files
├── .storybook/             # Storybook configuration
│   ├── main.js
│   └── preview.js
├── .gitignore
├── next.config.js
├── package.json
└── tsconfig.json

Factors to Consider When Choosing a Structure

Choosing a project structure depends on many factors, such as

1. Size of project: If the project is large Choose a structure that makes it easy to manage and expand your project.
2. Size of development team: If you have a large team You should choose a structure that clearly separates each part for working together
3. Project Complexity: If the project is complex. You should choose a structure that can handle those complexities
4. Technologies used: Technologies used such as Next.js, TypeScript, and Storybook may be properly structured and recommended

Best Practices for Project Structure

• Keep Components Small and Reusable: Components should do one thing and do it well. Reuse components across

the project.

• Use Contexts Wisely: Leverage React Context API to manage state across components that need access to the same data.
• Organize Styles: Organize your CSS/SASS files efficiently, using CSS modules or styled-components for modularity.
• Utilize TypeScript for Type Safety: Define types and interfaces to ensure type safety and better code readability.
• Write Tests: Include unit and integration tests for components and utilities to ensure functionality.

Tools to Consider

• Storybook: For UI Component development and testing
• Jest: For testing and checking code
• ESLint: For checking and formatting code
• Prettier: for automatic code formatting
• Husky & Lint-Staged: for setting up pre-commit hooks
• Next.js Custom Server: for using server-side logic

Hope this information helps you choose the right project structure for your Frontend development!

The above is the detailed content of How many types of frontend project structures are there?. For more information, please follow other related articles on the PHP Chinese website!