5
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

はじめに

通常、React では props を通じて親コンポーネントから子コンポーネントへ値や関数の受け渡しを行います。
しかし、特定のケースにおいてはこれが面倒に感じてしまうパターンがあります。

いわゆるprops のバケツリレーが発生してしまうんですね。

これの回避のために、React では Context というものが用意されています。
今回はこの Context についてのお話を 3 回に分けてお話しします。

第 1 回では「Context いつ使用するべきいつ使用するべきではないか」 ← イマココ
第 2 回では「Context の使い方
第 3 回では「Context を使う際にどんなことに気をつければいいか

についてお話しします。

いつ使用するべきか

先に記載した通り、props のバケツリレーを無くしたいと思ったシーンです。
以下のようなシーンでは使うと便利です。

1. 認証情報やページ全体で使うテーマの場合

以下のように、認証情報を持ったAuthenticationProviderでベースとなる_app.tsx を囲むことでアプリケーション全体に配布することができ、各コンポーネントで props を経由することなく、直接認証情報を入手することができます。

pages/_app.tsx
import { AuthenticationProvider } from "@/AuthenticationProvider";
import type { AppProps } from "next/app";

export default function MyApp({ Component, pageProps }: AppProps) {
  return (
    <AuthenticationProvider>
      <Component {...pageProps} />
    </AuthenticationProvider>
  );
}

2. 親から子、子から孫と何重にも同じ値を受け渡ししないといけない場合

1 と似たようなケースではありますが、何重にも props を受け渡さないといけないケースにも有用です。
一概に何段目からというのは特に決まってないですが、次のどういうシーンで使うべきではないのか?を見てチームで話し合うのが良いかと思います。

いつ使用するべきではないか

ネストが深くない値の受け渡しに関してはメリットよりデメリットが大きくなります。
なぜなら再利用性が下がるからです。

子コンポーネント側では、useContextという hooks を用い、配布された値や関数を参照しますが、
これは親が Provider に囲まれているという前提のコードになってしまいます。

つまり子が親に依存し、再利用性が失われる訳です。
まさに子が親のContextを知ってしまうわけですね。

なので、使わなくていいシーンでは使わない。使う場合も用法を守る必要がある。
ということを覚えておいてください。

まとめ

いかがでしたでしょうか?
今回は、Context というものについての概要として

  • いつ使用するべきか
  • いつ使用するべきではないか

について話しました。
次回、Context の使い方について書いていければと思います。

5
3
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
5
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?