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

More than 1 year has passed since last update.

こぼのフロントエンドレビュー帳Advent Calendar 2022

Day 13

【React】Context を使おうと思った時に気をつけること

Posted at

はじめに

本記事はシリーズものです。

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

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

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

第 1 回では「Context いつ使用するべきでいつ使用するべきではないか
第 2 回では「Context の使い方
第 3 回では「Context を使おうと思った時に気をつけること」 ← イマココ

についてお話しします。

Context を使おうと思った時に気をつけること

0. そもそもContextが必要なのかどうかを考える

にも書きましたが、Contextは乱用してしまうと保守性を下げる可能性があります。
Contextを使うと、それを利用したコンポーネントがContextProviderで囲まれている前提のコードになってしまうためですね。

つまり、捉え方によると、子が親に依存する状態になります。

なので、そもそも必要なのかどうかということを考えましょう。

にもありますが、propsのバケツリレーが悪いものだとは僕も思いません。

型を書くのが面倒というのであれば、

に書いたように、ComponentPropsWithoutRefというものを使えば、親が子に依存するという構成を貫き通すことができます。

それでも必要だという判断になった場合は以下のことを気にしてください。

再レンダリングを意識する

詳しくは以下の記事を見ていただければと思いますが、Contextが保持するステートが変わった場合、意図した部分以外が再レンダリングされる可能性があります。

ステートを配布するProviderと更新関数を配布するProviderを分けましょう。という話。

記事の中ではuseMemo、React.memoによる再レンダリングを防ぐ手法も書かれていますが、基本的には使用側がProviderの中身を意識することなく使えるのが望ましいかなと思うので、ちゃんと分けましょう。

まとめ

Contextは便利ですが、一種、グローバルステートのような扱いにもなりますし、保守性を下げてしまう可能性もあります。

使うべきなのか?ということを考えた上で、使うのであれば再レンダリングを起こさない設計を貫きましょう。

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