フロントエンドプロジェクトの構造は何種類ありますか?

フロントエンド プロジェクトの構築は、堅牢で保守が容易なアプリケーションを開発するために非常に重要です。適切な構造により、コードが理解しやすくなります。機能を効率的に拡張できます特に使用するときは開発中の Next.js と TypeScript は、一般的に使用されるいくつかのプロジェクト構造です。

1. 基本構造

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 は、サイズと機能に基づいてコンポーネントを分離することを強調する UI デザインの概念です。原子、分子、生物、テンプレート、ページの 5 つのレベルに分けることができます

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. 機能ベースの構造

機能ベースの構造は、新しい機能の管理と拡張を容易にするもう 1 つのアプローチです。簡単です

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. NX または Turborepo によるモノレポ構造

この構造は、複数のプロジェクトまたはモジュールを 1 か所にまとめたプロジェクト管理です。開発の各部分を明確に分離する必要がある大規模なチームまたはプロジェクトに適しています

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. 階層化されたアーキテクチャ構造

階層化されたアーキテクチャ設計により、プロジェクト機能を簡単に分離できます

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. ストーリーブックを使用したコンポーネント駆動構造

Storybook の使用は、分離された UI コンポーネントの体系的なテストと開発です。コンポーネントの機能を簡単にテストできます

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

構造を選択する際に考慮すべき要素

プロジェクト構造の選択は、次のような多くの要素に依存します。

1. プロジェクトのサイズ: プロジェクトが大きい場合プロジェクトの管理と拡張が簡単になる構造を選択してください。
2. 開発チームの規模: 大規模なチームがある場合連携して作業するために、各部分を明確に分離した構造を選択する必要があります
3. プロジェクトの複雑さ: プロジェクトが複雑な場合。それらの複雑さを処理できる構造を選択する必要があります
4. 使用されているテクノロジー: Next.js、TypeScript、Storybook などの使用されているテクノロジーは、適切に構成され、推奨されている可能性があります

プロジェクト構造のベスト プラクティス

• コンポーネントを小さく再利用可能に保つ: コンポーネントは 1 つのことを適切に実行する必要があります。
全体でコンポーネントを再利用する

プロジェクト

• コンテキストを賢く使用する: React Context API を活用して、同じデータにアクセスする必要があるコンポーネント全体の状態を管理します。
• スタイルの整理: CSS モジュールまたはモジュール化されたスタイル付きコンポーネントを使用して、CSS/SASS ファイルを効率的に整理します。
• 型の安全性のために TypeScript を利用する: 型とインターフェイスを定義して、型の安全性とコードの読みやすさを確保します。
• テストの作成: 機能を確認するために、コンポーネントとユーティリティの単体テストと統合テストを含めます。

考慮すべきツール

• ストーリーブック: UI コンポーネントの開発とテスト用
• Jest: コードのテストとチェック用
• ESLint: コードのチェックとフォーマット用
• Prettier: 自動コードフォーマット用
• Husky & Lint-Stages: コミット前フックのセットアップ用
• Next.js カスタム サーバー: サーバー側ロジックを使用するため

この情報がフロントエンド開発に適切なプロジェクト構造の選択に役立つことを願っています!

以上がフロントエンドプロジェクトの構造は何種類ありますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。