もう迷わない！React createContext完全ガイド【2024年最新版】

By /

はい、承知いたしました。ReactのcreateContextに関する詳細なガイド記事を、指定された要件（約5000語、記事内容の直接表示）に従って作成します。

もう迷わない！React createContext完全ガイド【2024年最新版】

React開発の世界へようこそ！コンポーネントベースのアーキテクチャは、UIを再利用可能な部品に分割し、開発を効率化してくれます。しかし、アプリケーションが成長するにつれて、コンポーネント間で状態（データ）を共有する必要が出てきます。そのとき、多くの開発者が直面するのが「Props Drilling（プロップスのバケツリレー）」という課題です。

あるコンポーネントから、何階層も下の深い階層にあるコンポーネントへデータを渡したい場合、中間に位置するすべてのコンポーネントを経由してpropsをリレーのように渡し続ける必要があります。これはコードを複雑にし、保守性を著しく低下させます。

もし、コンポーネントツリーの頂上から目的のコンポーネントへ、データを瞬間移動させることができたらどうでしょう？

それを可能にするのが、Reactに標準で搭載されているContext API、そしてその中核をなすReact.createContextです。

この記事は、createContextをマスターするための完全ガイドです。基礎的な使い方から、useReducerとの組み合わせによる高度な状態管理、パフォーマンス最適化の秘訣、そしてTypeScriptを使った型安全な実装まで、2024年現在のベストプラクティスを網羅的に解説します。

この記事を読み終える頃には、あなたはcreateContextに関するあらゆる迷いから解放され、自信を持ってアプリケーションの状態管理を設計できるようになっているはずです。さあ、React状態管理の新たな扉を開きましょう！

第1章: React Contextとは何か？

まず、Contextがどのような問題を解決するために存在するのか、その核心的なアイデアを理解することから始めましょう。

1-1. Contextの核心的アイデア

Reactの基本的なデータフローは、親コンポーネントから子コンポーネントへの単方向です。これはpropsを通じて行われます。このシンプルさはReactの大きな利点ですが、アプリケーションが複雑になると限界が見えてきます。

例えば、以下のようなコンポーネントツリーを想像してみてください。

App
└── Page
└── Layout
└── Header
└── UserAvatar (ユーザー情報を表示したい)

Appコンポーネントが持っているユーザー情報を、一番深い階層にあるUserAvatarコンポーネントで表示したい場合、propsを使ってデータを渡すと次のようになります。

  1. App → Pageへuserを渡す
  2. Page → Layoutへuserを渡す
  3. Layout → Headerへuserを渡す
  4. Header → UserAvatarへuserを渡す

Page、Layout、Headerは、user情報を自分自身では使わないにもかかわらず、ただ子コンポーネントへ渡すためだけにpropsを受け取る必要があります。これがProps Drillingです。

Context APIは、この問題を解決するための仕組みです。Contextは、コンポーネントツリー内に一種の「ワープゾーン」を作成します。データを共有したいコンポーネントツリーの頂点にProvider（提供者）を設置し、データを受け取りたいコンポーネントで直接そのデータをConsumer（消費者）として受け取ることができます。

これにより、中間のコンポーネントはpropsのバケツリレーから解放され、コードはクリーンで理解しやすくなります。

1-2. なぜContextが必要なのか？ – Props Drilling問題の深掘り

言葉だけでは分かりにくいかもしれませんので、具体的なコードでProps Drillingの問題点を見てみましょう。

“`jsx
// Props Drillingが発生している例
function App() {
const user = { name: “Alice”, avatarUrl: “…” };
return ;
}

function Page({ user }) {
// Pageコンポーнент自体はuserを使わない
return ;
}

function Layout({ user }) {
// Layoutコンポーネント自体もuserを使わない
return (


…

);
}

function Header({ user }) {
// Headerコンポーネント自体もuserを使わない
return (


);
}

function UserAvatar({ user }) {
// やっとここでuserが使われる
return {user.name};
}
“`

このコードの問題点は明白です。

  • 保守性の低下: userオブジェクトの構造が変わった場合、関係するすべての中間コンポーネントのpropsの型定義（TypeScriptを使っている場合）などを修正する必要があるかもしれません。
  • 再利用性の低下: Layoutコンポーネントを別の場所で使いたくても、user propを渡さないといけないため、再利用しにくくなります。
  • コードの冗長化: 不要なpropsの受け渡しがコードを長く、読みにくくします。

Contextは、これらの問題をエレガントに解決してくれるのです。

1-3. Context APIの3つの主要要素

Context APIは、主に3つの要素から構成されています。

  1. React.createContext(defaultValue)

    • Contextオブジェクトを作成するための関数です。この関数を呼び出すと、{ Provider, Consumer }というプロパティを持つオブジェクトが返されます。
    • 引数defaultValueは、ツリー内に適切なProviderが見つからなかった場合にのみ使用されるデフォルト値です。

  2. Context.Provider

    • Contextオブジェクトから提供されるコンポーネントです。このコンポーネントでラップされた配下の子孫コンポーネントは、Providerが持つ値を購読できるようになります。
    • 共有したい値をvalueというpropに渡します。
    • <MyContext.Provider value={/* 共有したい値 */}>

  3. useContext(MyContext) フック (または Context.Consumer)

    • Providerから提供された値を読み取るための仕組みです。
    • useContextフックは、関数コンポーネント内でContextの値をシンプルに受け取るための現代的な方法であり、現在はこちらが主流です。
    • const value = useContext(MyContext);
    • Context.Consumerは、クラスコンポーネントや、フックが使えない場面で利用されるRender Propsパターンのコンポーネントです。

次の章から、これらの要素を実際に使って、シンプルなアプリケーションを構築していきましょう。

第2章: createContextの基本的な使い方

理論を学んだところで、いよいよ実践です。ここでは、テーマ（ライトモード/ダークモード）を切り替える機能をContextを使って実装してみましょう。

2-1. ステップ・バイ・ステップ：初めてのContext作成

Contextを使った実装は、以下の3つのステップで進めます。

ステップ1: createContextでContextオブジェクトを作成する

まず、状態を共有するためのContextを作成します。新しいファイル（例: contexts/ThemeContext.js）を作成し、以下のように記述します。

“`javascript
// contexts/ThemeContext.js
import { createContext } from ‘react’;

// 1. Contextオブジェクトを作成
// デフォルト値として ‘light’ を設定
export const ThemeContext = createContext(‘light’);
“`

ここでは、createContextの引数に'light'という文字列を渡しました。これはデフォルト値です。後で説明しますが、この値はProviderでラップされていないコンポーネントがこのContextを使おうとした場合に参照されます。

ステップ2: Providerでコンポーネントをラップする

次に、作成したContextのProviderを使って、状態を共有したい範囲のコンポーネントツリーをラップします。通常は、アプリケーションのルートに近いコンポーネント（例: App.js）で行います。

“`jsx
// App.js
import React, { useState } from ‘react’;
import { ThemeContext } from ‘./contexts/ThemeContext’;
import Page from ‘./Page’;

function App() {
const [theme, setTheme] = useState(‘light’); // テーマの状態を管理

const toggleTheme = () => {
setTheme(prevTheme => (prevTheme === ‘light’ ? ‘dark’ : ‘light’));
};

return (
// 2. Providerでラップし、value propに共有したい値を渡す



);
}

export default App;
“`

重要なのはThemeContext.Providerのvalue propです。ここには、子孫コンポーネントで共有したい値を渡します。今回は、現在のテーマの状態themeと、それを切り替えるための関数toggleThemeをオブジェクトとして渡しています。

ステップ3: useContextフックで値を受け取る

最後に、Providerの配下にあるコンポーネントでuseContextフックを使い、valueに渡された値を受け取ります。

“`jsx
// Button.js
import React, { useContext } from ‘react’;
import { ThemeContext } from ‘./contexts/ThemeContext’;

function Button() {
// 3. useContextフックで値を受け取る
const { theme, toggleTheme } = useContext(ThemeContext);

const style = {
backgroundColor: theme === ‘light’ ? ‘#fff’ : ‘#333’,
color: theme === ‘light’ ? ‘#000’ : ‘#fff’,
border: 1px solid ${theme === 'light' ? '#000' : '#fff'},
padding: ’10px’,
cursor: ‘pointer’
};

return (

);
}

export default Button;
“`

useContext(ThemeContext)を呼び出すだけで、App.jsのProviderがvalueに渡した{ theme, toggleTheme }オブジェクトを直接受け取ることができます。propsのバケツリレーはどこにもありません。これがContextの力です。

2-2. 実践的なサンプルコード：テーマ切り替え機能の実装（全体像）

それでは、ここまでの内容をまとめた完全なサンプルコードを見てみましょう。

contexts/ThemeContext.js
“`javascript
import { createContext } from ‘react’;

// デフォルト値はProviderがない場合にのみ使われる
// 実践的には、カスタムフックでnullチェックをするため、nullにすることが多い
export const ThemeContext = createContext(null);
“`

App.js
“`jsx
import React, { useState, useMemo } from ‘react’;
import { ThemeContext } from ‘./contexts/ThemeContext’;
import Page from ‘./Page’;

function App() {
const [theme, setTheme] = useState(‘light’);

const toggleTheme = () => {
setTheme(prevTheme => (prevTheme === ‘light’ ? ‘dark’ : ‘light’));
};

// パフォーマンス最適化のため、valueに渡すオブジェクトをuseMemoでメモ化する
// (詳細は第4章で解説)
const themeValue = useMemo(() => ({
theme,
toggleTheme,
}), [theme]);

return (

App theme-${theme}}>

Welcome to my app


);
}

export default App;
“`

Page.js
“`jsx
import React from ‘react’;
import Header from ‘./Header’;
import Content from ‘./Content’;

function Page() {
return (


);
}

export default Page;
“`

Header.js
“`jsx
import React, { useContext } from ‘react’;
import { ThemeContext } from ‘./contexts/ThemeContext’;
import Button from ‘./Button’;

function Header() {
const { theme } = useContext(ThemeContext);

return (

1px solid ${theme === ‘light’ ? ‘#ccc’ : ‘#555’} }}>

My Awesome Header

);
}

export default Header;
“`

Content.js
“`jsx
import React, { useContext } from ‘react’;
import { ThemeContext } from ‘./contexts/ThemeContext’;

function Content() {
const { theme } = useContext(ThemeContext);

const style = {
    padding: '20px',
    backgroundColor: theme === 'light' ? '#f0f0f0' : '#282c34',
    color: theme === 'light' ? '#000' : '#fff',
    minHeight: '200px',
};

return (
    <main style={style}>
        <p>This is the main content of the page. The current theme is {theme}.</p>
        <p>Click the button in the header to switch themes.</p>
    </main>
);

}

export default Content;
“`

Button.js
“`jsx
import React, { useContext } from ‘react’;
import { ThemeContext } from ‘./contexts/ThemeContext’;

function Button() {
const { theme, toggleTheme } = useContext(ThemeContext);

const style = {
backgroundColor: theme === ‘light’ ? ‘#fff’ : ‘#555’,
color: theme === ‘light’ ? ‘#000’ : ‘#fff’,
border: ‘1px solid’,
padding: ‘8px 16px’,
cursor: ‘pointer’,
borderRadius: ‘4px’,
};

return (

);
}

export default Button;
“`

この構成により、Appコンポーネントが管理するthemeの状態が、Providerを通じてHeader, Content, Buttonコンポーネントに直接供給されているのが分かります。Pageコンポーネントはテーマ情報を全く意識する必要がありません。

2-3. defaultValueの正しい理解と使い方

createContext(defaultValue)のdefaultValueは、少し誤解されやすい概念です。

この値は、Providerが見つからなかった場合にのみ使われます。

言い換えれば、useContext(MyContext)を呼び出したコンポーネントが、MyContext.Providerでラップされたツリーの外に配置されていた場合に、defaultValueが返されます。

これは、コンポーネントを単体でテストする際に役立つことがあります。Providerをモックしなくても、コンポーネントがデフォルト値で動作することを確認できます。

しかし、実際のアプリケーション開発では、Contextを利用するコンポーネントは必ず対応するProviderの内部に配置されるべきです。そうでない場合、それはバグの可能性が高いです。

そのため、より堅牢な設計として、defaultValueにnullを設定し、後述するカスタムフック内でProviderの存在をチェックするパターンがよく用いられます。これにより、開発中にProviderの配置を忘れるというミスを防ぐことができます。

“`javascript
// defaultValueをnullに設定
export const ThemeContext = createContext(null);

// カスタムフックでチェック
export const useTheme = () => {
const context = useContext(ThemeContext);
if (context === null) {
// Providerでラップされていない場合にエラーを投げる
throw new Error(‘useTheme must be used within a ThemeProvider’);
}
return context;
}
“`

このパターンについては、第4章で詳しく解説します。

第3章: useContextとuseReducerによる高度な状態管理

useStateとuseContextの組み合わせはシンプルで強力ですが、アプリケーションの状態管理ロジックが複雑になってくると限界が見えてきます。例えば、ショッピングカートのように、複数のアクション（商品の追加、削除、数量の変更など）があり、それらが互いに関連している状態を管理する場合です。

このような場面で輝くのが、useReducerフックです。そしてuseContextとuseReducerを組み合わせることで、React標準機能だけで非常に洗練された状態管理パターンを構築できます。

3-1. useStateの限界とuseReducerの登場

useStateは、単一の独立した状態や、更新ロジックが単純な場合に最適です。しかし、状態更新ロジックが複雑化すると、setStateを呼び出す部分がコンポーネント内に散らばり、見通しが悪くなります。

“`jsx
// useStateで複雑な状態を管理する例（あまり良くない）
function CartManager() {
const [cart, setCart] = useState({ items: [], total: 0 });

const addItem = (item) => {
// …アイテム追加と合計金額計算ロジック
setCart(…);
};

const removeItem = (itemId) => {
// …アイテム削除と合計金額計算ロジック
setCart(…);
};

// …さらに他の更新ロジックが続く
}
“`

useReducerは、このような問題を解決するために設計されました。

  • 状態更新ロジックの分離: useReducerは、reducer関数という形で状態更新ロジックをコンポーネントの外に切り出すことができます。これにより、コンポーネントはUIの描画に集中でき、ロジックは純粋な関数としてテストしやすくなります。
  • アクションによる更新: 状態の更新をdispatch({ type: 'ADD_ITEM', payload: ... })のようなactionオブジェクトを通じて行います。これにより、「何が起きたか」が明確になり、デバッグが容易になります。

useReducerの基本的な構文はconst [state, dispatch] = useReducer(reducer, initialState);です。

3-2. createContextとuseReducerの組み合わせパターン

このパワフルなuseReducerをcreateContextと組み合わせることで、アプリケーション全体で共有される複雑な状態を、一貫性のある方法で管理できます。

このパターンの基本的な考え方は次の通りです。

  1. アプリケーションのグローバルな状態（state）と、それを更新するためのdispatch関数をuseReducerで作成する。
  2. createContextでContextオブジェクトを作成する。
  3. Context.Providerのvalueに、{ state, dispatch }というオブジェクトを渡す。
  4. 子孫コンポーネントはuseContextを使ってstateを読み取ったり、dispatchを呼び出して状態更新をトリガーしたりする。

これにより、かつてReduxライブラリが担っていたような役割の多くを、Reactの標準機能だけで実現できるのです。

3-3. 実践的なサンプルコード：ショッピングカート機能の実装

それでは、ショッピングカート機能をuseContextとuseReducerで実装してみましょう。

ステップ1: ContextとReducerの定義 (contexts/CartContext.js)

“`javascript
import { createContext, useReducer, useContext } from ‘react’;

// 1. Actionの型を定義（なくても動くが、定義すると分かりやすい）
const ActionTypes = {
ADD_ITEM: ‘ADD_ITEM’,
REMOVE_ITEM: ‘REMOVE_ITEM’,
UPDATE_QUANTITY: ‘UPDATE_QUANTITY’,
};

// 2. Reducer関数を定義
// stateとactionを受け取り、新しいstateを返す純粋な関数
const cartReducer = (state, action) => {
switch (action.type) {
case ActionTypes.ADD_ITEM: {
const existingItem = state.items.find(item => item.id === action.payload.id);
if (existingItem) {
// すでにカートにあれば数量を増やす
return {
…state,
items: state.items.map(item =>
item.id === action.payload.id ? { …item, quantity: item.quantity + 1 } : item
),
};
}
// カートになければ新しく追加
return {
…state,
items: […state.items, { …action.payload, quantity: 1 }],
};
}
case ActionTypes.REMOVE_ITEM: {
return {
…state,
items: state.items.filter(item => item.id !== action.payload.id),
};
}
case ActionTypes.UPDATE_QUANTITY: {
return {
…state,
items: state.items.map(item =>
item.id === action.payload.id ? { …item, quantity: action.payload.quantity } : item
).filter(item => item.quantity > 0), // 数量が0になったら削除
};
}
default:
throw new Error(Unknown action type: ${action.type});
}
};

// 3. Contextを作成
const CartStateContext = createContext(null);
const CartDispatchContext = createContext(null);

// 4. Providerコンポーネントを作成
export function CartProvider({ children }) {
const initialState = { items: [] };
const [state, dispatch] = useReducer(cartReducer, initialState);

return (


{children}


);
}

// 5. カスタムフックを作成（重要！）
export const useCartState = () => {
const context = useContext(CartStateContext);
if (context === null) {
throw new Error(‘useCartState must be used within a CartProvider’);
}
return context;
};

export const useCartDispatch = () => {
const context = useContext(CartDispatchContext);
if (context === null) {
throw new Error(‘useCartDispatch must be used within a CartProvider’);
}
return context;
};
``
**ポイント:** ここではパフォーマンス最適化のため、state用のContextとdispatch用のContextを分けています。詳細は次の章で解説しますが、dispatch関数は再生成されないため、dispatchだけを必要とするコンポーネントはstate`の変更で再レンダリングされなくなります。

ステップ2: アプリケーションをProviderでラップ (App.js)

“`jsx
import { CartProvider } from ‘./contexts/CartContext’;
import ProductList from ‘./ProductList’;
import CartDisplay from ‘./CartDisplay’;

function App() {
return (

My E-Commerce Site


);
}
“`

ステップ3: カスタムフックを使って状態を操作するコンポーネント (ProductList.js)

“`jsx
import { useCartDispatch } from ‘./contexts/CartContext’;

const products = [
{ id: 1, name: ‘React Book’, price: 30 },
{ id: 2, name: ‘Node.js Book’, price: 35 },
{ id: 3, name: ‘CSS Book’, price: 25 },
];

function ProductList() {
const dispatch = useCartDispatch(); // dispatch関数を取得

const handleAddToCart = (product) => {
dispatch({ type: ‘ADD_ITEM’, payload: product });
};

return (

Products

    {products.map(product => (

  • {product.name} – ${product.price}

    • ))}

);
}
``useCartDispatchフックを使うことで、dispatch`関数を簡単に取得し、カートに商品を追加するアクションを発行できています。

ステップ4: カスタムフックを使って状態を表示するコンポーネント (CartDisplay.js)

“`jsx
import { useCartState, useCartDispatch } from ‘./contexts/CartContext’;

function CartDisplay() {
const { items } = useCartState(); // stateを取得
const dispatch = useCartDispatch(); // dispatchも取得

const total = items.reduce((sum, item) => sum + item.price * item.quantity, 0);

return (

Shopping Cart

{items.length === 0 ? (

Your cart is empty.

) : (
<>

    {items.map(item => (

  • {item.name} – ${item.price} x {item.quantity}

    • ))}

Total: ${total.toFixed(2)}

)}

);
}
``useCartState`フックでカートの状態を購読し、内容を表示しています。

このパターンにより、状態管理のロジックがcartReducerに集約され、各コンポーネントは責務が明確になりました。これはスケール可能で保守しやすい、非常に強力な設計です。

第4章: パフォーマンス最適化とベストプラクティス

Context APIは非常に便利ですが、使い方を誤るとアプリケーションのパフォーマンスに悪影響を与える可能性があります。ここでは、Contextにまつわる「再レンダリングの罠」を理解し、それを回避するための最適化テクニックとベストプラクティスを学びます。

4-1. Contextと再レンダリングの罠

Contextの最も重要な特性を覚えておいてください。

Providerのvalue propが変更されると、そのContextをuseContextで購読しているすべてのコンポーネントが再レンダリングされます。

これは、そのコンポーネントが実際にvalueの変更された部分を使っているかどうかに関わらず発生します。例えば、value={{ state, dispatch }}を渡している場合、stateが変更されると、dispatchしか使っていないコンポーネントも再レンダリングされてしまいます。これがパフォーマンス低下の主な原因です。

4-2. value propに渡すオブジェクトの問題点

よくあるアンチパターンは、value propにインラインでオブジェクトや配列を渡すことです。

“`jsx
function App() {
const [theme, setTheme] = useState(‘light’);

// 親コンポーネントが再レンダリングされるたびに、
// この { theme } は新しいオブジェクトとして再生成される
return (

{/ … /}

);
}
“`

このコードでは、Appコンポーネントが（例えば自身の親からのprops変更などで）再レンダリングされるたびに、value={{ theme }}は新しいメモリアドレスを持つ新しいオブジェクトを生成します。Reactはこれを「valueが変更された」と判断し、このContextを購読しているすべての子孫コンポーネントを再レンダリングさせてしまいます。たとえthemeの値自体が変わっていなくてもです。

4-3. 最適化テクニック

この問題を解決し、不要な再レンダリングを防ぐためのテクニックがいくつかあります。

テクニック1: useMemoでvalueをメモ化する

valueに渡すオブジェクトや配列をuseMemoフックでメモ化（キャッシュ）することで、依存配列の値が変更された場合にのみ新しいオブジェクトが生成されるようになります。

“`jsx
import { useState, useMemo } from ‘react’;

function App() {
const [theme, setTheme] = useState(‘light’);
const toggleTheme = () => { / … / };

// themeかtoggleThemeが変更されたときだけ、新しいオブジェクトを生成
const themeValue = useMemo(() => ({
theme,
toggleTheme
}), [theme, toggleTheme]); // toggleThemeは通常不変だが、念のため含める

return (

{/ … /}

);
}
``
これにより、Appコンポーネントが他の理由で再レンダリングされても、themeの値が変わらない限りthemeValue`は同じオブジェクトを参照し続けるため、Contextのコンシューマーは再レンダリングされません。

テクニック2: useCallbackで関数をメモ化する

valueに渡すオブジェクトに関数が含まれている場合、その関数もuseCallbackでメモ化することが重要です。これにより、親コンポーネントが再レンダリングされるたびに新しい関数が生成されるのを防ぎます。

“`jsx
import { useState, useMemo, useCallback } from ‘react’;

function App() {
const [theme, setTheme] = useState(‘light’);

// toggleTheme関数をメモ化。依存配列が空なので、初回レンダリング時のみ生成される。
const toggleTheme = useCallback(() => {
setTheme(prev => (prev === ‘light’ ? ‘dark’ : ‘light’));
}, []); // 依存配列は空

const themeValue = useMemo(() => ({
theme,
toggleTheme
}), [theme, toggleTheme]);

return (

{/ … /}

);
}
“`

テクニック3: Contextを分割する（最も強力なテクニック）

前述のショッピングカートの例でも使った、最も効果的な最適化手法の一つが「Contextの分割」です。

  • 頻繁に更新される状態（state）
  • ほとんど、あるいは全く変わらない更新関数（dispatchやsetter）

これらを別々のContextに分離します。

“`javascript
// contexts/CartContext.js

// stateを保持するContext
const CartStateContext = createContext(null);
// dispatch関数を保持するContext
const CartDispatchContext = createContext(null);

export function CartProvider({ children }) {
const [state, dispatch] = useReducer(cartReducer, initialState);

return (


{children}


);
}
“`

この設計のメリットは絶大です。

  • カートの中身を表示するだけのコンポーネントは、useCartState()を使ってCartStateContextだけを購読します。
  • 商品をカートに追加するボタンのようなコンポーネントは、useCartDispatch()を使ってCartDispatchContextだけを購読します。

dispatch関数はコンポーネントのライフサイクルを通じて不変（再生成されない）です。そのため、stateがどれだけ頻繁に更新されても、dispatchしか必要としないコンポーネントは再レンダリングのトリガーを受け取りません。これにより、再レンダリングの範囲を必要最小限に抑えることができます。

4-4. カスタムプロバイダーとカスタムフックのパターン

これまで見てきたように、Contextを効果的に使うには、状態管理のロジック（useStateやuseReducer）、パフォーマンス最適化（useMemo）、そしてContextのProviderを組み合わせる必要があります。これらのロジックをすべてApp.jsのようなルートコンポーネントに書くと、すぐに見通しが悪くなります。

そこで推奨されるのが、カスタムプロバイダーとカスタムフックのパターンです。

  1. カスタムプロバイダーコンポーネント: Contextに関連するすべてのロジックをカプセル化したコンポーネントを作成します。（例: ThemeProvider, CartProvider）
  2. カスタムフック: useContextを直接呼び出す代わりに、Contextをラップしたカスタムフックを作成します。（例: useTheme, useCartState）

第3章で実装したCartProviderとuseCartState/useCartDispatchは、まさにこのパターンの実践例です。

このパターンのメリットは以下の通りです。

  • 関心の分離: 状態管理のロジックがコンポーネントから完全に分離され、再利用とテストが容易になります。
  • 実装の隠蔽: コンポーネントの利用者は、useTheme()を呼び出すだけで済み、内部でuseContextが使われていることや、パフォーマンス最適化がどのように行われているかを意識する必要がありません。
  • 堅牢性の向上: カスタムフック内でProviderの存在チェックを行えるため、Providerでラップし忘れるというミスを開発中に検知できます。
  • 将来の変更への柔軟性: 将来、Contextの実装を別の状態管理ライブラリ（例: Zustand）に置き換えたくなった場合でも、カスタムフックの内部実装を変更するだけで済み、アプリケーションの他の部分に影響を与えません。

常にこのパターンに従うことを強く推奨します。

第5章: Contextと他の状態管理ライブラリの比較

Context APIは強力ですが、万能ではありません。Reactのエコシステムには、他にも多くの優れた状態管理ライブラリが存在します。ここでは、代表的なライブラリとContext APIを比較し、どのような場合にどれを選択すべきかの指針を示します。

5-1. Context API vs. Redux

Reduxは、長年にわたりReactの大規模アプリケーションにおける状態管理のデファクトスタンダードでした。

  • Context API

    • Pros:
      • Reactに標準搭載されており、追加のライブラリは不要。
      • APIがシンプルで学習コストが比較的低い。
      • 小〜中規模のアプリケーションや、特定の範囲の状態（テーマ、認証情報など）を共有するのに最適。
    • Cons:
      • パフォーマンスチューニング（useMemoなど）を開発者が意識的に行う必要がある。
      • Redux DevToolsのような強力なデバッグツールが標準ではない。
      • ミドルウェア（非同期処理など）の仕組みが組み込まれていない。

  • Redux (with Redux Toolkit)

    • Pros:
      • 予測可能な状態コンテナで、大規模で複雑な状態の管理に優れる。
      • Redux DevToolsによる時間旅行デバッグなど、強力な開発者体験。
      • 豊富なミドルウェア（Thunk, Saga）による非同期処理の体系的な管理。
      • 確立されたエコシステムとベストプラクティス。
    • Cons:
      • ボイラープレート（定型的なコード）が多い（Redux Toolkitで大幅に改善されたが、依然として存在）。
      • 学習コストが高い。セットアップがContextより複雑。

選択の指針:
まずContext APIから始めるのが良いでしょう。特にuseReducerとカスタムフックのパターンを使えば、かなりの規模のアプリケーションに対応できます。アプリケーションが非常に大規模になり、多くの開発者が関わる、あるいは複雑な非同期処理や状態のデバッグが頻繁に必要になった場合に、Reduxへの移行を検討するのが現実的なアプローチです。

5-2. Context API vs. Zustand / Jotai

近年、Reduxよりもシンプルで軽量な状態管理ライブラリが人気を集めています。その代表格がZustandやJotaiです。

  • Zustand / Jotai
    • Pros:
      • 非常にシンプルなAPIで、ボイラープレートがほとんどない。
      • Context APIが抱える「購読コンポーネント全体の再レンダリング問題」を、セレクター（Zustand）やアトミックな状態管理（Jotai）によって根本的に解決している。パフォーマンス最適化の手間が少ない。
      • Reduxのような厳格なルールがなく、柔軟に使える。
    • Cons:
      • 外部ライブラリへの依存が発生する。
      • Reduxほど確立されたエコシステムやデバッグツールはない（ただし、シンプルなDevToolsは提供されている）。

選択の指針:
Context APIのパフォーマンス問題（不要な再レンダリング）に直面し、手動での最適化が煩雑になってきたが、Reduxを導入するほど大掛かりにはしたくない、という場合に最適な選択肢です。特にZustandは、フックベースのシンプルなAPIがuseStateの感覚に近く、導入が非常に容易なため人気があります。

5-3. 2024年における状態管理の選択肢

現代のReact開発では、単一のツールですべてを管理するのではなく、状態の種類に応じてツールを使い分けるハイブリッドアプローチが主流です。

  • サーバー状態 (Server State): APIから取得するデータなど。

    • TanStack Query (旧React Query) や SWR を使うのがベストプラクティス。これらのライブラリは、キャッシュ、再検証、ローディング/エラーステートの管理などを自動で行ってくれます。Context APIでサーバー状態を管理するのは、多くのボイラープレートが必要となり非推奨です。

  • グローバルなUI状態 (Global UI State): アプリケーション全体で共有されるクライアント側の状態（テーマ、モーダルの開閉状態、認証情報など）。

    • Context API が最も手軽で基本的な選択肢。
    • パフォーマンスが懸念される場合や、よりシンプルな書き味を求めるなら Zustand が有力候補。
    • 非常に大規模で複雑な場合は Redux Toolkit。

  • ローカルなコンポーネント状態 (Local Component State): 特定のコンポーネント内でのみ使われる状態。

    • useState や useReducer を使うのが基本。何でもかんでもグローバルにする必要はありません。

適材適所でツールを選択することが、効率的で保守性の高いアプリケーションを構築する鍵となります。

第6章: TypeScriptとContextを組み合わせる

TypeScriptは、現代のReact開発において型安全性を保証し、開発体験を向上させるために不可欠なツールです。createContextをTypeScriptと組み合わせることで、より堅牢で予測可能な状態管理を実現できます。

6-1. 型安全なContextの作成

Contextに型を定義するには、createContextのジェネリクス<T>を使用します。

よく使われるパターンは、Contextの型とnullのユニオン型を定義し、createContextの初期値にnullを渡す方法です。

“`typescript
import { createContext } from ‘react’;

// 1. Contextで共有する値の型を定義
interface ThemeContextType {
theme: ‘light’ | ‘dark’;
toggleTheme: () => void;
}

// 2. createContextに型と初期値(null)を渡す
export const ThemeContext = createContext(null);
“`

nullを初期値にするのは、カスタムフック内でProviderの存在をチェックし、nullの可能性を排除するためです。これにより、コンポーネント側でのnullチェックが不要になります。

6-2. 型推論を活かすカスタムフック

前述のnullチェックを含んだ、型安全なカスタムフックを作成しましょう。

“`typescript
import { useContext } from ‘react’;
import { ThemeContext, ThemeContextType } from ‘./ThemeContextFile’; // 型もインポート

export const useTheme = (): ThemeContextType => {
const context = useContext(ThemeContext);

// Providerでラップされていない場合、contextはnullになる
if (context === null) {
// 開発中にエラーに気づけるように、明確なエラーメッセージを投げる
throw new Error(‘useTheme must be used within a ThemeProvider’);
}

// このチェックにより、以降contextはThemeContextType型であることが保証される
return context;
};
“`

このuseThemeフックを使うコンポーネントでは、返り値がThemeContextTypeであることがTypeScriptによって保証されます。

“`typescript
// Component.tsx
import { useTheme } from ‘./useTheme’;

function MyComponent() {
// const { theme, toggleTheme } の型は自動的に推論され、nullの可能性はない
const { theme, toggleTheme } = useTheme();

return (

);
}
“`

このパターンにより、Providerのセットアップ忘れを防ぎつつ、利用側での煩わしいnullチェックをなくし、最高の開発体験を提供できます。

6-3. useReducerと組み合わせる際の型定義

useReducerと組み合わせる場合は、Stateの型とActionの型を定義することが重要です。特にActionの型にはDiscriminated Unions（判別可能なユニオン型）を使うのがベストプラクティスです。

“`typescript
// types.ts
export interface CartItem {
id: number;
name: string;
price: number;
quantity: number;
}

export interface CartState {
items: CartItem[];
}

// Discriminated Unionsを使ってActionの型を定義
type AddAction = { type: ‘ADD_ITEM’; payload: { id: number; name: string; price: number } };
type RemoveAction = { type: ‘REMOVE_ITEM’; payload: { id: number } };
type UpdateQuantityAction = { type: ‘UPDATE_QUANTITY’; payload: { id: number; quantity: number } };

export type CartAction = AddAction | RemoveAction | UpdateQuantityAction;
“`

これらの型をreducerとProviderに適用します。

“`typescript
// CartProvider.tsx
import { useReducer, ReactNode } from ‘react’;
import { CartState, CartAction } from ‘./types’;

// … (Contextの作成)

const cartReducer = (state: CartState, action: CartAction): CartState => {
switch (action.type) {
case ‘ADD_ITEM’:
// action.payload は { id, name, price } 型であることが保証される
// …
case ‘REMOVE_ITEM’:
// action.payload は { id } 型であることが保証される
// …
// …
}
};

export function CartProvider({ children }: { children: ReactNode }) {
const initialState: CartState = { items: [] };
const [state, dispatch] = useReducer(cartReducer, initialState);

// dispatchの型はReactが自動的に Dispatch<CartAction> と推論してくれる

// … (Providerの提供)
}
“`

このように型を厳密に定義することで、dispatchするactionのtypeに応じてpayloadの型が正しくなければTypeScriptがエラーを検知してくれます。これにより、状態更新ロジックにおける多くのバグを未然に防ぐことができます。

まとめ

お疲れ様でした！この長い旅路を経て、あなたはReact.createContextを使いこなすための知識とテクニックを身につけました。

最後に、この記事で学んだ重要なポイントを振り返りましょう。

  • Contextの基本: createContextは「Props Drilling」問題を解決し、コンポーネントツリーをまたいでデータを直接渡すための強力なメカニズムです。Providerで値を提供し、useContextで受け取ります。
  • 実践的な状態管理: useStateとの組み合わせはシンプルですが、複雑な状態にはuseReducerとの組み合わせが最適です。状態更新ロジックをreducerに分離し、stateとdispatchをContext経由で提供します。
  • パフォーマンスが鍵: Contextのvalueが変わるとコンシューマーは再レンダリングされます。useMemoやuseCallbackによるメモ化、そしてContextの分割（状態と更新関数の分離）が不要な再レンダリングを防ぐための最も効果的なテクニックです。
  • 最強の設計パターン: 状態管理ロジックをカプセル化するカスタムプロバイダーと、useContextをラップしてnullチェックなどを行うカスタムフックを常にセットで使いましょう。これにより、コードはクリーンで、堅牢で、保守しやすくなります。
  • 適材適所のツール選択: Context APIは銀の弾丸ではありません。サーバー状態にはTanStack Query、よりシンプルなグローバル状態管理にはZustandなど、状況に応じて最適なツールを選択する視点が重要です。
  • 型と共にあれ: TypeScriptと組み合わせることで、Contextはさらに強力になります。型定義とカスタムフックを駆使して、型安全で快適な開発体験を手に入れましょう。

createContextは、React開発者にとって必須のツールです。しかし、その力を最大限に引き出すには、その特性とトレードオフを正しく理解し、適切な設計パターンを適用することが不可欠です。

この記事が、あなたのReact開発における状態管理の迷いをなくし、よりクリーンで、よりパフォーマンスが高く、よりスケールするアプリケーションを構築するための一助となれば幸いです。

さあ、自信を持ってcreateContextを使いこなし、素晴らしいReactアプリケーションを創造してください！ Happy coding

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール