1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

コンポーネントを分ける必要性! ~1つのファイルにすべて書くと修正がタイヘン~

Last updated at Posted at 2025-11-17

※ こちらの「コード品質向上の重要性:読みやすく、使いやすいシステムを作るために」という記事を読んでから、本記事を読んでいただけると幸いです。

また、「コード品質向上の重要性:読みやすく、使いやすいシステムを作るために」の補足記事として、以下の記事も作成しました。こちらも併せて読んでいただけると幸いです。

はじめに

Reactを使った開発で、コンポーネントの構成に悩んだことはありませんか?
特に、小さなプロジェクトから始まったはずなのに、いつの間にか1つのファイルにたくさんのコードが詰め込まれてしまい、修正や機能追加のたびに「どこを直せばいいんだ…?」と頭を抱える経験は、多くの開発者が通る道かもしれません。
本記事では、Node.js (TypeScript) と React を利用している皆さんに向けて、なぜコンポーネントを分割する必要があるのか、そして1つのファイルにすべてを詰め込むことの弊害を、具体的なコード例を交えながら解説します。

コンポーネント分割のメリットを理解し、より保守しやすく、再利用性の高いコードを書くためのヒントになれば幸いです。

1. ファイルにすべて書くと何が問題なのか?

もし、すべてのロジックやUIを1つのコンポーネントファイルにまとめてしまったら、どうなるでしょうか?想像してみてください。以下の問題点が上がると思います。

1.1. 可読性の低下

数百行、あるいは数千行にも及ぶファイルの中から、特定の機能を探し出すのは至難の業です。コードを読むのに時間がかかり、新しい開発者がプロジェクトに参加した際の学習コストも高くなります。

1.2. 変更・修正の困難さ

ある機能に修正が必要になったとき、その修正が他の機能にどのような影響を与えるかを把握するのが非常に困難になります。少しの変更が思わぬバグを引き起こし、「芋づる式」に修正箇所が増えていく、 なんてことにもなりかねません。

1.3. 再利用性の喪失

1つのコンポーネントに多くの役割が詰め込まれていると、そのコンポーネントを別の場所で再利用することが難しくなります。特定の機能だけを使い回したい場合でも、不要な機能まで一緒に持ってきてしまうため、結果的に同じようなコードをコピー&ペーストしてしまうという WET (We Enjoy Typing/Write Everything Twice) な状態に陥りやすくなります。

1.4. テストの複雑化

単一のコンポーネントが多くの機能を持つ場合、そのコンポーネントをテストするためには、それぞれの機能に関するあらゆるケースを考慮しなければなりません。テストコードも肥大化し、記述やメンテナンスが非常に困難になります。

2. コンポーネントを分割するメリット

では、コンポーネントを適切に分割することで、どのようなメリットが得られるのでしょうか?

2.1. 可読性の向上

各ファイルが小さくなり、それぞれのコンポーネントが明確な役割を持つため、コードの見通しが格段に良くなります。「このコンポーネントは何をしているのか」が一目でわかるようになり、コードを理解するスピードが上がります。

2.2. 変更・修正の容易さ

特定の機能に修正が必要な場合、その機能が担当するコンポーネントだけを修正すればよくなります。他の部分への影響が限定されるため、バグのリスクを減らし、安心して変更を加えることができます。

2.3. コンポーネントの再利用性

単一の責任を持つ小さなコンポーネントは、様々な場所で再利用しやすくなります。例えば、ボタンや入力フォーム、モーダルウィンドウなど、汎用的なUI要素を一度作成すれば、アプリケーション全体で一貫したUIを素早く構築できます。これは開発効率の向上に大きく貢献します。

2.4. テストのしやすさ

それぞれのコンポーネントが独立して機能するため、単体テストが非常に容易になります。特定のコンポーネントの動作を分離して検証できるため、テストコードもシンプルになり、効率的なテストプロセスを確立できます。

3. 具体例で見てみよう

それでは、実際のコードで 「悪い例」 と 「良い例」 を比較してみましょう。
今回は、ユーザープロフィールとそのユーザーが投稿した記事、さらにその記事に紐づくコメントを表示するページを例にとります。

3.1 悪い例:すべてを1ファイルに書いた場合

この例では、ユーザー情報、投稿リスト、各投稿のコメントリストの表示ロジックがすべて UserProfilePage.tsxという1つのファイルに集約されています。

UserProfilePage.tsx
import React, { useState, useEffect } from 'react';

// 仮の型定義(本来はtypes.tsなどにまとめるべきですが、今回は悪い例としてここに記述)  
interface User {  
  id: number;  
  name: string;  
  email: string;  
}

interface Post {  
  id: number;  
  title: string;  
  content: string;  
  comments: Comment[]; // 投稿にコメントが紐づく  
}

interface Comment {  
  id: number;  
  text: string;  
  author: string;  
}

const UserProfilePage = () => {  
  const [user, setUser] = useState<User | null>(null);  
  const [posts, setPosts] = useState<Post[]>([]);

  useEffect(() => {  
    // useEffect内で非同期関数を定義して呼び出す  
    const fetchData = async () => {  
      try {  
        // ユーザー情報と投稿情報を並列で取得  
        const [userDataResponse, postsDataResponse] = await Promise.all([  
          fetch('/api/user/1'),  
          fetch('/api/user/1/posts')  
        ]);

        setUser(await userDataResponse.json());  
        setPosts(await postsDataResponse.json());  
      } catch (error) {  
        console.error("Error fetching data:", error);  
        // エラーハンドリング(例: エラーメッセージを表示するなど)  
      }  
    };

    fetchData();  
  }, []);

  if (!user) {  
    return <div>Loading user profile...</div>;  
  }

  return (  
    <div>  
      <h1>{user.name}</h1>  
      <p>{user.email}</p>

      <h2>Posts</h2>  
      {posts.length === 0 ? (  
        <p>No posts found.</p>  
      ) : (  
        <ul>  
          {posts.map(post => (  
            <li key={post.id}>  
              <h3>{post.title}</h3>  
              <p>{post.content}</p>  
              <h4>Comments</h4>  
              {post.comments.length === 0 ? (  
                <p>No comments for this post.</p>  
              ) : (  
                <ul>  
                  {post.comments.map(comment => (  
                    <li key={comment.id}>  
                      <p>{comment.text}</p>  
                      <span>- {comment.author}</span>  
                    </li>  
                  ))}  
                </ul>  
              )}  
            </li>  
          ))}  
        </ul>  
      )}  
    </div>  
  );  
};

export default UserProfilePage;

このコードでは、ユーザー情報の表示、投稿リストのループ処理、各投稿のコメントリストのループ処理、そしてデータフェッチのロジックがすべてUserProfilePageという1つのコンポーネントに詰め込まれています。これでは、例えばコメントの表示方法を変更したい場合でも、この大きなファイルを読み解く必要があり、修正が大変です。

3.2. 良い例:コンポーネントを分割した場合

次に、コンポーネントを適切に分割し、インターフェースも専用ファイルにまとめた例を見てみましょう。
最終的なフォルダ構造は以下のようになります。

src/  
├── types.ts  
├── components/  
│   ├── UserInfo.tsx  
│   ├── UserPosts.tsx  
│   ├── PostItem.tsx  
│   └── PostComments.tsx  
└── pages/  
    └── UserProfilePage.tsx

まず、types.ts に共通のインターフェースを定義します。

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

export interface Post {  
  id: number;  
  title: string;  
  content: string;  
  comments: Comment[];  
}

export interface Comment {  
  id: number;  
  text: string;  
  author: string;  
}

そして、各機能に特化したコンポーネントを作成します。

UserProfilePage.tsx (全体の構成)

src/pages/UserProfilePage.tsx
import React, { useState, useEffect } from 'react';  
import { UserInfo } from '../components/UserInfo';  
import { UserPosts } from '../components/UserPosts';  
import { User, Post } from '../types';

const UserProfilePage = () => {  
  const [user, setUser] = useState<User | null>(null);  
  const [posts, setPosts] = useState<Post[]>([]);

  useEffect(() => {  
    const fetchData = async () => {  
      try {  
        const [userDataResponse, postsDataResponse] = await Promise.all([  
          fetch('/api/user/1'),  
          fetch('/api/user/1/posts')  
        ]);

        setUser(await userDataResponse.json());  
        setPosts(await postsDataResponse.json());  
      } catch (error) {  
        console.error("Error fetching data:", error);  
      }  
    };

    fetchData();  
  }, []);

  if (!user) {  
    return <div>Loading user profile...</div>;  
  }

  return (  
    <div>  
      <UserInfo user={user} />  
      <UserPosts posts={posts} />  
    </div>  
  );  
};

export default UserProfilePage;

UserInfo.tsx (ユーザー情報の表示のみを担当)

src/components/UserInfo.tsx
import React from 'react';  
import { User } from '../types';

interface UserInfoProps {  
  user: User;  
}

export const UserInfo: React.FC<UserInfoProps> = ({ user }) => {  
  return (  
    <div>  
      <h1>{user.name}</h1>  
      <p>{user.email}</p>  
    </div>  
  );  
};

UserPosts.tsx (投稿リストの表示と各投稿コンポーネントのレンダリングを担当)

src/components/UserPosts.tsx
import React from 'react';  
import { PostItem } from './PostItem';  
import { Post } from '../types';

interface UserPostsProps {  
  posts: Post[];  
}

export const UserPosts: React.FC<UserPostsProps> = ({ posts }) => {  
  if (posts.length === 0) {  
    return <p>No posts found.</p>;  
  }

  return (  
    <div>  
      <h2>Posts</h2>  
      <ul>  
        {posts.map(post => (  
          <PostItem key={post.id} post={post} />  
        ))}  
      </ul>  
    </div>  
  );  
};

PostItem.tsx (個々の投稿の表示とそれに紐づくコメントリストのレンダリングを担当)

src/components/PostItem.tsx
import React from 'react';  
import { PostComments } from './PostComments';  
import { Post } from '../types';

interface PostItemProps {  
  post: Post;  
}

export const PostItem: React.FC<PostItemProps> = ({ post }) => {  
  return (  
    <li>  
      <h3>{post.title}</h3>  
      <p>{post.content}</p>  
      <PostComments comments={post.comments} />  
    </li>  
  );  
};

PostComments.tsx (投稿に紐づくコメントリストの表示のみを担当)

src/components/PostComments.tsx
import React from 'react';  
import { Comment } from '../types';

interface PostCommentsProps {  
  comments: Comment[];  
}

export const PostComments: React.FC<PostCommentsProps> = ({ comments }) => {  
  if (comments.length === 0) {  
    return <p>No comments for this post.</p>;  
  }

  return (  
    <div>  
      <h4>Comments</h4>  
      <ul>  
        {comments.map(comment => (  
          <li key={comment.id}>  
            <p>{comment.text}</p>  
            <span>- {comment.author}</span>  
          </li>  
        ))}  
      </ul>  
    </div>  
  );  
};

このように分割することで、各コンポーネントが特定の役割に集中し、コードの重複も解消されました。例えば、コメントの表示形式を変更したい場合は PostComments.tsx だけを修正すればよくなり、他のコンポーネントに影響を与える心配が格段に減ります。

4. コンポーネント分割の考え方

コンポーネントを分割する際のガイドラインとして、いくつかの原則が役立ちます。

4.1. 単一責任の原則 (Single Responsibility Principle: SRP)

これはSOLID原則の「S」にあたるもので、「1つのコンポーネントは1つの理由によってのみ変更されるべきである」という考え方です。つまり、それぞれのコンポーネントは、アプリケーション内の特定の機能や責任のみを担うべきだということです。上記の良い例では、UserInfo はユーザー情報の表示、PostItem は個々の投稿の表示、というように、それぞれのコンポーネントが単一の責任を持っています。

4.2. 共通ロジックの抽出

複数のコンポーネントで同じようなロジックやUIパターンが使われている場合、それらを共通のコンポーネントやカスタムフックとして抽出することを検討しましょう。これにより、DRY原則を徹底し、コードの重複を避けられます。今回の例では、types.ts にインターフェースをまとめることで、型の定義の重複を避けました。

4.3. UIとロジックの分離

コンポーネントを、「見た目を担当する(Presentational Component)」ものと、「データ取得や状態管理などのロジックを担当する(Container Component)」ものに分けるという考え方もあります。これにより、UIの変更とロジックの変更がそれぞれ独立して行えるようになり、保守性が向上します。

まとめ

1つのファイルにすべてを書き続けることは、最初は手軽に感じるかもしれませんが、プロジェクトが成長するにつれて、様々な問題を引き起こします。コンポーネントを適切に分割し、それぞれのコンポーネントに単一の責任を持たせることで、以下のようなメリットが得られます。

  • 可読性の向上:コードが読みやすくなり、理解しやすくなります。
  • 変更・修正の容易さ:特定の機能を修正する際の影響範囲が限定されます。
  • 再利用性の向上:汎用的なコンポーネントをアプリケーション全体で使い回せます。
  • テストのしやすさ:各コンポーネントを独立してテストできます。

最初は少し手間がかかるように感じるかもしれませんが、長期的な視点で見れば、コンポーネント分割は開発効率とコード品質を大きく向上させる投資です。

おわりに

本記事が、皆さんのReact開発におけるコンポーネント設計の一助となれば幸いです。もし、今回の内容に関してさらに深掘りしたい点や、疑問に思うことがあれば、ぜひコメントで教えてください!

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?