なぜリアクトで関数型プログラミングを志向するのか

テーマを選択

기록 상세 정보를 불러오는 중입니다.

아티클을 불러오는 중입니다.

なぜリアクトで関数型プログラミングを志向するのか | chaen

リアクト(React)は最近数年間、関数型プログラミング(Functional Programming, FP) を志向するようになりました。
単純なUIコンポーネントから複雑なアプリケーション構造に至るまで、関数型アプローチの利点を積極的に活用しています。
今回の記事では、リアクトで関数型プログラミングを志向する理由とそれぞれの根拠を体系的に整理してみたいと思います。

👍 テストの容易性

関数型プログラミングの核心は「純粋関数(ピュアファンクション)」です。純粋関数とは、入力が同じであれば常に同じ出力を返し、外部状態を変更しない関数を指します。

関数型コンポーネントのテストの利点

依存性の最小化: コンポーネントが外部状態や副作用に依存しない場合、そのコンポーネントの結果は入力(props)だけで予測できます。
単体テストの最適化: モックやスタブが不要になる場合が多く、テストコードも短くなり理解しやすくなります。
再利用性の強化: フックや関数型ヘルパーを複数のコンポーネントで独立して活用できます。

簡潔な例の比較

クラス型コンポーネントのテスト:

js

関数型コンポーネント:

js

関数型コンポーネントはロジックとレンダリングを分離でき、各々を独立してテストできます。

純粋関数の例:

js

👍 最適化の便利さ

関数型プログラミングではデータは不変（イミュータブル）に扱うのが基本です。

不変性の核心原理

状態管理の不変性: 既存のオブジェクトを直接変更せず、新しいオブジェクトを生成して状態を変えます。
参照比較効率性（Shallow Compare）: オブジェクトの参照のみ比較するため最適化が容易です。
予測可能性: 値が変わらないため予測可能なフローを維持できます。

最適化が容易になる理由

不変性を守るとリアクトの最適化ツールが非常に効果的に動作します：

React.memoの効率的な動作：

js

useMemoとuseCallbackの正確な依存性検出：

js

間違った方法 vs 正しい方法：

js

👍 変化検出の効率性

不変性を守ると参照比較（===）のみで状態変化の検出が可能になります。

参照比較の性能上の利点

深い比較 vs 参照比較：

js

リアクトの変化検出メカニズム

リアクトは状態が変わったか確認する際、Object.is()（ほぼ===と同じ）を使用します：

js

大容量データでの効率性

js

このように不変性を維持すれば、複雑なデータ構造でも変化検知がO(1)時間で行われ、性能上大きな利点を得ることができます。

👍 メモイゼーションと関数型の関係

メモイゼーション(Memoization) は同じ入力に対して計算を繰り返さずにキャッシュされた値を返す最適化技法です。関数型プログラミングは純粋関数(pure function) を前提とするため、メモイゼーションが非常に効果的です。

関数型プログラミングと相性が良い理由

純粋関数は常に同じ入力に対して同じ出力を返す → キャッシュするのに最適
副作用がないためキャッシュされた結果を再利用しても問題なし
代表的に、のようなフックもこの概念に基づく

例 - useMemo 最適化

js

純粋でない関数はメモイゼーションしにくい:

js

このように関数型の「不変性 + 純粋性」はメモイゼーションの前提条件と一致するため、両方の概念は互いを強化します。

👍 状態管理と可読性

関数型コンポーネントとフック(useState, useReducer)を活用することで状態管理コードが簡潔になります。

useReducerで複雑なロジック処理

js

カスタムフックでロジック分離

js

このようにするとUIレンダリングロジックとデータロジックを明確に分離でき、可読性が高まります。

📌 結論

リアクトが関数型プログラミングを採用する理由は、コードの明確さ、テストの容易さ、最適化と変化検知の効率性のためです。

テストコードの作成が簡単 - 純粋関数は入力と出力だけを確認すれば良いです
状態管理が直感的にでき - フックを通じたロジックの分離と再利用
性能最適化が予測可能に行われます - 不変性に基づく参照比較

関数型パラダイムはコンポーネントをモジュール化し、複雑度を制御するのに効果的な戦略です。

💭 フロントエンドvsバックエンドでのパラダイム選択

私の主観的な判断です。

フロントエンド(React) はUIレンダリング、状態変化検知、最適化、テストなどを効率良く行うために関数型パラダイムが適しているようです。

純粋性 + 不変性 → 状態追跡、再レンダリング制御に有利

一方、バックエンド(Node.js, Javaなど) では性能問題やリソース管理、プロセスフロー制御などでオブジェクト指向(OOP) が実用的であると思います。

純粋関数に基づいたデータフローを作る場合、性能よりも複雑性が増すこともあります。

区分	フロントエンド (React など)	バックエンド (Node.js, Java など)
主要考慮要素	UIレンダリング最適化、状態変化追跡	性能、リソース管理、トランザクションフロー
適したパラダイム	関数型プログラミング	オブジェクト指向プログラミング
長所	テストが容易、不変性で状態変化追跡、コンポーネント再利用性	クラスベース構造で責任の明確化、状態維持、接続中心の設計、複雑なロジックの構造化容易
短所	複雑な演算フローには不便、無分別なフックの乱用で可読性低下	テスト時の状態分離が難しい、再レンダリング最適化の構造は複雑

参考資料

class UserProfile extends React.Component {
  state = { name: '', loading: false };
  
  async componentDidMount() {
    this.setState({ loading: true });
    const user = await fetchUser(this.props.userId);
    this.setState({ name: user.name, loading: false });
  }
  
  render() {
    return <div>{this.state.loading ? 'Loading...' : this.state.name}</div>;
  }
}
 
// テスト時にライフサイクルと状態を全て考慮する必要がある

function UserProfile({ userId }) {
  const { user, loading } = useUser(userId);
  
  if (loading) return <div>Loading...</div>;
  return <div>{user.name}</div>;
}
 
// テスト時にpropsのみ確認すれば良い (フックは別途テスト)

function formatPrice(price, currency = 'USD') {
  return `${currency} ${price.toFixed(2)}`;
}
 
// 入力だけで結果を予測可能
expect(formatPrice(10.5)).toBe('USD 10.50');
expect(formatPrice(20, 'KRW')).toBe('KRW 20.00');

// 不変性を守る場合
const TodoItem = React.memo(({ todo, onToggle }) => (
  <div onClick={() => onToggle(todo.id)}>
    {todo.text} {todo.completed ? '✓' : '○'}
  </div>
));
 
// propsが参照上同じであれば再レンダリングされません

function TodoList({ todos, filter }) {
  // todos配列が新たに生成される時のみフィルタリング再実行
  const filteredTodos = useMemo(() => 
    todos.filter(todo => todo.category === filter), 
    [todos, filter]
  );
  
  // 依存性が変わらなければ関数再生成されません
  const handleToggle = useCallback((id) => 
    setTodos(prev => prev.map(todo => 
      todo.id === id ? { ...todo, completed: !todo.completed } : todo
    )), 
    []
  );
  
  return <div>{/* ... */}</div>;
}

// ❌ 直接修正 - 最適化ツールが変化を検知できません
function badUpdate() {
  const newTodos = todos;
  newTodos[0].completed = true;
  setTodos(newTodos); // 参照が同じなので再レンダリングされません
}
 
// ✅ 新しいオブジェクト生成 - 最適化ツールが正確に動作
function goodUpdate() {
  setTodos(prev => prev.map((todo, index) => 
    index === 0 ? { ...todo, completed: true } : todo
  ));
}

// ❌ 深い比較 - すべての属性を再帰的に確認（遅い）
function deepEqual(obj1, obj2) {
  // オブジェクトのすべてのkey-valueを比較する必要があります
  return JSON.stringify(obj1) === JSON.stringify(obj2);
}
 
// ✅ 参照比較 - メモリアドレスのみ確認（速い）
function shallowEqual(obj1, obj2) {
  return obj1 === obj2; // 一度の比較で終了
}

function Counter() {
  const [count, setCount] = useState(0);
  const [user, setUser] = useState({ name: 'John', age: 25 });
  
  // ✅ 原始値は自動的に不変性保証
  const increment = () => setCount(prev => prev + 1);
  
  // ✅ オブジェクトは新たに生成しないと変化検知されません
  const updateAge = () => setUser(prev => ({ ...prev, age: prev.age + 1 }));
  
  // ❌ このようにすると変化が検知されません
  const wrongUpdate = () => {
    user.age += 1;
    setUser(user); // 同じ参照なので再レンダリングされません
  };
}

function DataTable({ items }) {
  // itemsが参照上同じならソートを再度行いません
  const sortedItems = useMemo(() => {
    console.log('ソート実行！'); // いつ実行されるか確認可能
    return [...items].sort((a, b) => a.name.localeCompare(b.name));
  }, [items]);
  
  return (
    <table>
      {sortedItems.map(item => (
        <tr key={item.id}>
          <td>{item.name}</td>
          <td>{item.price}</td>
        </tr>
      ))}
    </table>
  );
}

function ProductList({ products, searchTerm }) {
  // searchTermやproductsが変わらない限りフィルタリングを再実行しません
  const filteredProducts = useMemo(() => {
    console.log('フィルタリング実行!');
    return products.filter(p => 
      p.name.toLowerCase().includes(searchTerm.toLowerCase())
    );
  }, [products, searchTerm]);
  
  return <div>{filteredProducts.map(/* ... */)}</div>;
}

// ❌ 純粋ではない - 外部状態に依存
let discount = 0.1;
function calculatePrice(price) {
  return price * (1 - discount); // 外部変数参照
}
 
// ✅ 純粋 - 全ての入力がパラメータで渡される
function calculatePrice(price, discount = 0) {
  return price * (1 - discount);
}

function todoReducer(state, action) {
  switch (action.type) {
    case 'ADD_TODO':
      return [...state, { id: Date.now(), text: action.text, completed: false }];
    case 'TOGGLE_TODO':
      return state.map(todo => 
        todo.id === action.id ? { ...todo, completed: !todo.completed } : todo
      );
    case 'DELETE_TODO':
      return state.filter(todo => todo.id !== action.id);
    default:
      return state;
  }
}
 
function TodoApp() {
  const [todos, dispatch] = useReducer(todoReducer, []);
  
  return (
    <div>
      <button onClick={() => dispatch({ type: 'ADD_TODO', text: 'New Todo' })}>
        Add Todo
      </button>
      {/* ... */}
    </div>
  );
}

function useLocalStorage(key, initialValue) {
  const [value, setValue] = useState(() => {
    const saved = localStorage.getItem(key);
    return saved ? JSON.parse(saved) : initialValue;
  });
  
  useEffect(() => {
    localStorage.setItem(key, JSON.stringify(value));
  }, [key, value]);
  
  return [value, setValue];
}
 
// さまざまなコンポーネントで再利用可能
function Settings() {
  const [theme, setTheme] = useLocalStorage('theme', 'light');
  const [language, setLanguage] = useLocalStorage('language', 'ko');
  
  return <div>{/* 設定UI */}</div>;
}

なぜリアクトで関数型プログラミングを志向するのか

コメント

NAVER Boostcamp Web・Mobile 10期メンバーシップ — グループプロジェクト 4〜7週目振り返り

フロントエンド UI アーキテクチャパターン — MVC、MVP、MVVM、Flux

👍 テストの容易性

関数型コンポーネントのテストの利点

簡潔な例の比較

👍 最適化の便利さ

不変性の核心原理

最適化が容易になる理由

👍 変化検出の効率性

参照比較の性能上の利点

リアクトの変化検出メカニズム

大容量データでの効率性

👍 メモイゼーションと関数型の関係

関数型プログラミングと相性が良い理由

例 - useMemo 最適化

👍 状態管理と可読性

useReducerで複雑なロジック処理

カスタムフックでロジック分離

📌 結論

💭 フロントエンドvsバックエンドでのパラダイム選択

純粋関数に基づいたデータフローを作る場合、性能よりも複雑性が増すこともあります。

参考資料

NAVER Boostcamp Web・Mobile 10期メンバーシップ — グループプロジェクト 4〜7週目振り返り

フロントエンド UI アーキテクチャパターン — MVC、MVP、MVVM、Flux

コメント

관련 기록

NAVER Boostcamp Web・Mobile 10期 メンバーシップ — グループプロジェクト 4〜7週目振り返り

フロントエンド UI アーキテクチャパターン — MVC、MVP、MVVM、Flux

👍 テストの容易性

関数型コンポーネントのテストの利点

簡潔な例の比較

👍 最適化の便利さ

不変性の核心原理

最適化が容易になる理由

👍 変化検出の効率性

参照比較の性能上の利点

リアクトの変化検出メカニズム

大容量データでの効率性

👍 メモイゼーションと関数型の関係

関数型プログラミングと相性が良い理由

例 - useMemo 最適化

👍 状態管理と可読性

useReducerで複雑なロジック処理

カスタムフックでロジック分離

📌 結論

💭 フロントエンドvsバックエンドでのパラダイム選択

純粋関数に基づいたデータフローを作る場合、性能よりも複雑性が増すこともあります。

参考資料

관련 기록

NAVER Boostcamp Web・Mobile 10期 メンバーシップ — グループプロジェクト 4〜7週目振り返り

フロントエンド UI アーキテクチャパターン — MVC、MVP、MVVM、Flux

NAVER Boostcamp Web・Mobile 10期メンバーシップ — グループプロジェクト 4〜7週目振り返り

NAVER Boostcamp Web・Mobile 10期メンバーシップ — グループプロジェクト 4〜7週目振り返り