0
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?

バックエンド開発者が戸惑うReactの状態管理

Posted at

バックエンドの開発者がReactプロジェクトに参画する必要に迫られた場合、直面しそうなReactの状態管理と、解決アプローチについて解説します。

はじめに:バックエンド開発者の視点

バックエンド開発では、状態の変更は直接的で分かりやすいものが一般的です。しかし、Reactに初めて触れると、その不変性(イミュータビリティ)を重視したアプローチに戸惑うことがあります。この記事は、特にバックエンド開発者がReactの状態管理を理解し、効果的に活用するためのガイドとなることを目指しています。

Reactの状態管理における主な課題

不変性の原則との格闘

Reactの不変性の原則は、一見すると過度に複雑に感じられます。特に、オブジェクトの更新において、直接的な変更が許されないことは、バックエンド開発者にとって直感に反する場合があります。例えば、以下のようなケースを考えてみましょう:

// 直感的だが推奨されないアプローチ
const handleUpdate = () => {
  user.name = "新しい名前";  // 直接的な変更は避けるべき
};

// Reactの推奨アプローチ
const handleUpdate = () => {
  setUser({ ...user, name: "新しい名前" });
};

複雑なステート更新の処理

アプリケーションが複雑になるにつれ、状態の更新ロジックも複雑になります。特に、ネストされたオブジェクトの更新や、配列内のオブジェクトの更新は、不変性を保ちながら行う必要があり、コードが冗長になりがちです。

// ネストされたオブジェクトの更新例
const updateUserAddress = () => {
  setUser(prevUser => ({
    ...prevUser,
    address: {
      ...prevUser.address,
      city: "新しい都市"
    }
  }));
};

実践的な解決アプローチ

1. ImmerによるイミュータブルなState管理

Immerは、イミュータブルなデータ構造を扱う際の複雑さを大幅に軽減してくれるライブラリです。特にバックエンド開発者にとって、従来のミュータブルな操作に近い書き方でイミュータブルな更新を実現できる点が大きな利点となります。

基本的な使用方法

import { produce } from 'immer';

// 従来の方法(ネストされたオブジェクトの更新)
const updateUserTraditional = (user) => ({
  ...user,
  address: {
    ...user.address,
    city: "新しい都市"
  }
});

// Immerを使用した方法
const updateUserWithImmer = produce((draft) => {
  draft.address.city = "新しい都市";
});

useImmerによる状態管理の簡素化

React専用のuseImmerフックを使用することで、さらに直感的な状態管理が可能になります:

import { useImmer } from "use-immer";

const TodoList = () => {
  const [todos, setTodos] = useImmer([
    {
      id: "task1",
      title: "バックエンドAPIの実装",
      done: false,
      subtasks: [
        { id: "sub1", title: "DB設計", done: false },
        { id: "sub2", title: "エンドポイント実装", done: false }
      ]
    }
  ]);

  // ネストされたデータの更新が簡単
  const completeSubtask = (taskId, subtaskId) => {
    setTodos(draft => {
      const task = draft.find(t => t.id === taskId);
      const subtask = task.subtasks.find(st => st.id === subtaskId);
      subtask.done = true;
    });
  };

  // 配列操作も直感的
  const addSubtask = (taskId) => {
    setTodos(draft => {
      const task = draft.find(t => t.id === taskId);
      task.subtasks.push({
        id: `sub${Date.now()}`,
        title: "新しいサブタスク",
        done: false
      });
    });
  };
};

Immerの効果的なユースケース

1. 複雑なネストを持つオブジェクトの更新
const updateDeepNested = produce((draft) => {
  draft.users[0].orders[1].items[2].quantity += 1;
  // ネストされたパスのすべての中間オブジェクトが
  // 自動的に適切にコピーされます
});
2. 条件付き更新の実装
const conditionalUpdate = produce((draft) => {
  draft.items.forEach(item => {
    if (item.stock < 10) {
      item.status = "要補充";
      item.notification = true;
    }
  });
});
3. 複数の更新をトランザクション的に扱う
const updateTodoStatus = produce((state) => {
  // 複数の更新を1つのイミュータブルな操作として処理
  state.todos.forEach(todo => {
    if (todo.deadline < new Date()) {
      todo.status = 'overdue';
      todo.needsAttention = true;
    }
  });
  state.lastUpdated = new Date();
});

パフォーマンスに関する注意点

  1. Immerは内部でProxyを使用するため、極端に頻繁な更新が必要な場合は、従来の手動更新の方が効率的な場合があります。

  2. 大規模なデータ構造を扱う場合は、更新が必要な部分のみを選択的にproduceで処理することで、パフォーマンスを最適化できます:

// 大きなデータの一部分のみを更新
const updateSpecificPart = produce(draft => {
  // draft.hugeData ではなく、必要な部分のみを更新
  draft.hugeData.specificSection.value = newValue;
});

2. カスタムフックによる状態管理の抽象化

複雑な状態更新ロジックは、カスタムフックとして抽象化することで、再利用性と可読性を向上させることができます:

const useUserState = (initialUser) => {
  const [user, setUser] = useState(initialUser);

  const updateName = useCallback((newName) => {
    setUser(prev => ({ ...prev, name: newName }));
  }, []);

  const updateAddress = useCallback((newAddress) => {
    setUser(prev => ({ ...prev, address: { ...prev.address, ...newAddress } }));
  }, []);

  return { user, updateName, updateAddress };
};

3. 状態管理ライブラリの適切な選択

Reduxは強力ですが、小規模なアプリケーションでは過剰になる場合があります。代わりに、Context APIやZustandなどの軽量な状態管理ライブラリの使用を検討しましょう:

import create from 'zustand';

const useStore = create((set) => ({
  user: null,
  setUser: (user) => set({ user }),
  updateUserName: (name) => set((state) => ({
    user: { ...state.user, name }
  }))
}));

パフォーマンスの最適化

React 18以降、状態更新に関するパフォーマンスは大幅に改善されていますが、以下の点に注意を払うことで、さらなる最適化が可能です。特に、useRefの適切な使用は、不必要な再レンダリングを防ぎ、アプリケーションのパフォーマンスを向上させる重要な要素となります:

useRefによるパフォーマンス最適化

useRefは、値の保持と参照を目的として使用され、その値が変更されても再レンダリングを引き起こしません。これは特に以下のような場合に有効です:

1. 再レンダリングが不要な値の保持

// 不適切な使用例(再レンダリングが発生)
const [counter, setCounter] = useState(0);

// 適切な使用例(再レンダリングが発生しない)
const counterRef = useRef(0);

const incrementCounter = () => {
  counterRef.current += 1;
  // 画面の更新が不要な場合、この方法が効率的
};

2. DOM要素への直接アクセス

const VideoPlayer = () => {
  const videoRef = useRef(null);

  const handlePlay = () => {
    videoRef.current.play();
    // DOMの直接操作が必要な場合、useRefが最適
  };

  return <video ref={videoRef} src="video.mp4" />;
};

3. 前回の値の保持(Previous Value Pattern)

const Component = ({ value }) => {
  const prevValueRef = useRef();

  useEffect(() => {
    prevValueRef.current = value;
  }, [value]);

  const prevValue = prevValueRef.current;

  if (value !== prevValue) {
    // 値が変更された時の処理
  }

  return <div>{/* コンポーネントの内容 */}</div>;
};

4. タイマーやイベントリスナーの参照管理

const IntervalComponent = () => {
  const intervalRef = useRef();

  useEffect(() => {
    intervalRef.current = setInterval(() => {
      // 定期的な処理
    }, 1000);

    return () => {
      clearInterval(intervalRef.current);
    };
  }, []);

  return <div>{/* コンポーネントの内容 */}</div>;
};

useRefの使用は、以下の原則に従って検討します:

  • 値の変更が画面の更新を必要としない場合
  • DOM要素への直接アクセスが必要な場合
  • コンポーネントのライフサイクル全体で値を保持する必要がある場合
  • クリーンアップが必要なリソース(タイマー、サブスクリプション)の管理

メモ化とパフォーマンス最適化の実践例

メモ化(useMemo, useCallback, memo)を適切に使用することで、効果的なパフォーマンス最適化が可能です。以下に、実践的な例を示します:

// 子コンポーネントのメモ化による最適化
const ChildComponent = memo(({ onIncrement }) => {
  console.log("Child component rendered");
  return (
    <button onClick={onIncrement}>
      カウントを増やす
    </button>
  );
});

// 親コンポーネントでのuseCallbackの適切な使用
const ParentComponent = () => {
  const [count, setCount] = useState(0);
  const [otherState, setOtherState] = useState(0);
  
  // useCallbackで関数をメモ化
  const handleIncrement = useCallback(() => {
    setCount(c => c + 1);  // 更新関数で前の値を参照
  }, []); 

  return (
    <div>
      <p>Count: {count}</p>
      <p>Other: {otherState}</p>
      <ChildComponent onIncrement={handleIncrement} />
      <button onClick={() => setOtherState(s => s + 1)}>
        別のステートを更新
      </button>
    </div>
  );
};

この例では:

  1. memoを使用して子コンポーネントの不要な再レンダリングを防いでいます
  2. useCallbackで関数をメモ化し、子コンポーネントへの不要な再レンダリングのトリガーを防いでいます
  3. useStateの更新関数を活用して、前の状態を安全に参照しています

useRefの適切な使用例

useRefは主に以下のようなケースで使用します:

// DOM要素への直接アクセスが必要な場合
const VideoPlayerComponent = () => {
  const videoRef = useRef(null);

  const handlePlay = () => {
    videoRef.current?.play();
  };

  return (
    <div>
      <video ref={videoRef} src="video.mp4" />
      <button onClick={handlePlay}>再生</button>
    </div>
  );
};

// インターバルやタイマーのクリーンアップ
const TimerComponent = () => {
  const [count, setCount] = useState(0);
  const timerRef = useRef(null);

  useEffect(() => {
    timerRef.current = setInterval(() => {
      setCount(c => c + 1);
    }, 1000);

    return () => {
      clearInterval(timerRef.current);
    };
  }, []);

  return <div>カウント: {count}</div>;
};

2. 状態の分割と最適化

大きな状態オブジェクトは、より小さな単位に分割することで、再レンダリングの範囲を最小限に抑えることができます:

// 推奨されないアプローチ
const [user, setUser] = useState({
  personalInfo: { /* ... */ },
  preferences: { /* ... */ },
  settings: { /* ... */ }
});

// 推奨されるアプローチ
const [personalInfo, setPersonalInfo] = useState({ /* ... */ });
const [preferences, setPreferences] = useState({ /* ... */ });
const [settings, setSettings] = useState({ /* ... */ });

まとめ

Reactの状態管理は、特にバックエンド開発者にとって最初は違和感を感じる部分かもしれません。しかし、その原則を理解し、適切なツールと手法を選択することで、効果的な状態管理を実現できます。

初めは戸惑うことも多いですが、慣れると細やかなアプリ開発が可能になり、提供したいユーザー体験が柔軟に開発できることに喜びを感じられると思います!

参考資料

0
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
0
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?