関数コンポーネントは関数型プログラミングを意味するのか？

長期的なReactユーザーは、Reactに2種類のコンポーネントがあることをご存知でしょう。

• クラスコンポーネント
• 関数コンポーネント

「クラス」と「関数」という言及から、当然ながら以下のような疑問が湧いてきます。

• クラスコンポーネントはOOP（オブジェクト指向プログラミング）と関連があるのか？
• 関数コンポーネントはFP（関数型プログラミング）と関連があるのか？

結局のところ、クラスコンポーネントがOOPに関連付けられている場合、OOPの原則（継承、カプセル化、ポリモーフィズムなど）がクラスベースのコンポーネントの開発を導く可能性があります。同様に、FPの原則が関数コンポーネントに影響を与える可能性があります。言い換えれば、これらのプログラミングパラダイムのベストプラクティスをReactプロジェクトに直接適用できるかもしれません。

では、関数コンポーネントと関数型プログラミングの関係は何でしょうか？この記事では、このトピックについて深く掘り下げます。

プログラミングパラダイムとDSL

まず、フレームワークの構文は、特定のドメインでの開発に合わせて調整された一種の**DSL（ドメイン固有言語）**であることを明確にしておく必要があります。

たとえば、Reactはビューを構築するためのDSLです。異なるプラットフォームがビュー用に異なるフレームワークを使用していますが、例えば：

• ウェブ用：ReactDOM
• ミニプログラム用：Taro
• ネイティブ開発用：ByteDanceの内部フレームワークReact Lynx

これらのフレームワークは一般的に同じDSL（React構文）に従います。このDSLは特定のプログラミングパラダイムに関連付けられていませんが、代わりにビュー開発に最適化された言語機能の集合として見なされるべきです。

したがって、React DSLの一部として：

• 関数コンポーネントはOOPの原則を具現化できます。
• クラスコンポーネントはFPの原則を反映できます。

これらの原則がビュー開発に役立つ限り、DSLに組み込むことができます。

たとえば、次の関数コンポーネントHeaderは、WelcomeMessageとLogoutButtonで構成されています。これは、OOPの継承よりも構成の原則を示しています。

function Header(props) {
  return (
    <div>
      <WelcomeMessage name={props.name} />
      <LogoutButton onClick={props.onLogout} />
    </div>
  );
}

同様に、クラスコンポーネントCpnを考えてみましょう。ここでは、状態countはミューテーション（this.state.count++）ではなく、イミュータブルなデータでthis.setStateを呼び出すことによって更新されます。

class Cpn extends React.Component {
  // ...
  onClick() {
    const count = this.state.count;
    this.setState({ count: count + 1 });
  }
  render() {
    // ...
  }
}

イミュータブルなデータの使用は、FPの原則を反映しています。

したがって、Reactの機能を検討する際には、次の3つのステップで考える必要があります。

1. Reactのコアな開発哲学とは何か？
2. この哲学を実装するために、さまざまなプログラミングパラダイムからどのようなアイデアが使用されているか？
3. これらのアイデアはReactでどのように適用されているか？

この思考プロセスを関数コンポーネントと関数型プログラミングの関係に適用すると、次のことがわかります。

• 関数コンポーネントは実装の結果（ステップ3）です。
• 関数型プログラミングはプログラミングパラダイム（ステップ2）です。

これにより、それらの関係が定義されます。関数コンポーネントは、複数のプログラミングパラダイム（主にOOPとFP）をReactに実装した結果であり、その過程でFPからいくつかのアイデアを借用しています。

関数コンポーネントは、Reactにおける関数型プログラミングの具現化としてのみ見なされるべきではありません。

関数コンポーネントの進化

前述の3ステップの思考プロセスを使用して、関数コンポーネントの進化を探ってみましょう。Reactの開発哲学は、次の式で最もよく表現されます。

UI = fn(snapshot);

この哲学を実装するには、2つの重要な要素が必要です。

• データスナップショット
• 関数マッピング

ここで、FPからのイミュータブルなデータは、データスナップショットのキャリアとしてより適しています。これが、Reactの状態がイミュータブルである理由です—状態の本質はスナップショットです。

関数マッピングのキャリアには、特定の要件はありません。Reactでは、すべての更新で再レンダリングがトリガーされ、レンダリングプロセス自体が関数マッピングプロセスです。入力はpropsとstateであり、出力はJSXです。

対照的に、VueコンポーネントはよりOOPの原則に沿っています。このVueのAppコンポーネントを考えてみましょう。

const App = {
  setup(initialProps) {
    const count = reactive({count: 0})
    const add = () => { count.value++ }
    return {count, add}
  }
  template: "...omitted"
}

コンポーネントのsetupメソッドは、初期化時に1回だけ実行されます。後続の更新は、クロージャ内の同じデータを操作します。これは、OOPのインスタンスの概念に対応します。

Reactは関数マッピングのキャリアに特別な要件を課していないため、クラスコンポーネントと関数コンポーネントの両方が実行可能なオプションです。

なぜ関数コンポーネントがクラスコンポーネントに取って代わったのか？

多くの人は、フックを介したロジックの再利用性の向上が、関数コンポーネントがクラスコンポーネントよりも優れている主な理由だと考えています。ただし、デコレーターベースのクラス開発モデルは、特にTypeScriptと組み合わせると、ロジックの再利用に効果的なアプローチであることが証明されています。

本当の理由は、関数コンポーネントが**UI = fn(snapshot)**の哲学をより良く実装できることにあります。

前述のように、式中のsnapshotは状態のスナップショットを表し、Reactには以下が含まれます。

• state
• props
• context

特定のコンポーネントについて、式UI = fn(snapshot)は、同一のスナップショットが同一の出力（JSX）を生成することを保証します。ただし、状態の更新により、データフェッチやDOM操作などの副作用もトリガーされる可能性があります。

クラスコンポーネントでは、これらの副作用ロジックはさまざまなライフサイクルメソッドに分散しており、Reactが制御するのが困難になっています。ただし、関数コンポーネントでは：

• 副作用はuseEffectに限定されています。Reactは、新しい副作用を適用する前に、前のレンダリングからの副作用がクリーンアップされることを保証します（useEffectの戻り値を介して）。
• refの伝播は、forwardRefなどのメカニズムによって制限され、潜在的な影響を制限しています。
• データフェッチの副作用は、以下に示すように、Suspenseによって管理されます。

function UserList({ id }) {
  const data = use(fetchUser(id));
  // ...
}

使用法：

<Suspense fallback={<div>Loading...</div>}>
  <UserList id={1} />
</Suspense>

要するに、関数コンポーネントは副作用が管理可能であることを保証し、同じスナップショット入力に対して一貫した出力を可能にします。これは、FPの純粋関数の概念に沿っており、関数コンポーネントがReactの主流の選択肢になった理由です。

結論

関数コンポーネントは、Reactにおける関数型プログラミングの直接的な実装ではなく、Reactのコアな哲学である**UI = fn(snapshot)**を実現するのに最適なキャリアです。Reactは、さまざまなプログラミングパラダイムから優れたアイデアを統合しており、FPが最も影響力があります。最終的に、すべての設計上の選択は、全体的な哲学に役立ちます。

---

Leapcellへようこそ。Node.jsプロジェクトのホスティングに最適です。

Leapcellは、Webホスティング、非同期タスク、Redisのための次世代サーバーレスプラットフォームです。

多言語サポート

• Node.js、Python、Go、またはRustで開発。

無制限のプロジェクトを無料でデプロイ

• 使用量に対してのみ支払い—リクエストなし、料金なし。

比類のない費用効率

• アイドル料金なしの従量課金制。
• 例：25ドルで、平均応答時間60msで694万リクエストをサポート。

合理化された開発者エクスペリエンス

• 簡単なセットアップのための直感的なUI。
• 完全に自動化されたCI/CDパイプラインとGitOps統合。
• 実用的な洞察のためのリアルタイムメトリックとロギング。

簡単なスケーラビリティと高性能

• 高い同時実行性を容易に処理するための自動スケーリング。
• 運用上のオーバーヘッドゼロ—構築に集中するだけです。

詳細については、ドキュメントをご覧ください。

Xでフォローしてください：@LeapcellHQ