Reactコンポーネントのstateを利用するシチュエーション

Question

Reactコンポーネント自身がstateを持つような実装は、具体的にはどんな時に利用していますか？

コンポーネント自身が単独で状態を持つ、ということだと理解していますが、単独で状態を持つシチュエーションというのが、今ひとつピンと来ません。

サンプルでは、カウンターや時計などを見かけますが、私自身もこれくらいしか思い浮かびません。

実際のアプリケーションでは、カウンターの状態（現在の値）も、他から参照して利用することがほとんどだと思います。そんな場合、stateを他から読み出す必要がありますが、stateでは、取り扱いにくいように思います。

情報を表示することに特化して、かつ、状態を管理しなければならない場合・・・ということで考えれば、
視覚効果の制御？などに絞られるのでしょうか？

現状、React+Reduxを基本として考えているのですが、コンポーネントstateの利用価値が理解できれば、そちらも使っていきたいと思っていますので、何か気づきをいただけるとありがたいです。

私もそう思う、や、こんな考え方もある気がする、など、疑問に対する回答出なくてもよいので、いろいろご意見いただけると助かります。

Answer 1

情報を表示することに特化して、かつ、状態を管理しなければならない場合・・・ということで考えれば、

視覚効果の制御？などに絞られるのでしょうか？

恐らくこの認識で間違いないと思います。

個人的なケースでお話させていただくと、

いくつかの画像情報をコンテナから配列で渡されて、
それを表示するようなコンポーネントを作成したことがあります。

縮小した画像をサムネで並べて、選択したものだけを大きくプレビューするようなありふれたものです。
この時にコンポーネントのstateで、選択した画像のインデックス、プレビュー時の動作を制御するフラグ等を持たせていました。
もちろんstoreに持たせることもできますが、
特定のコンポーネント内で完結する情報はコンポーネントのstateで持たせた方が開発側としても分かり易いと考えた上でのことです。

なので個人的には、コンポーネントの要件と相談してstateに持たせるかどうかを判断するしかないと思います。

Comments

[Meganezaru]

なるほど！このイメージなら、確かにコンポーネントのstateが適してそうですね。
理解しやすい例でした。ありがとうございました！

巷のsetStateなサンプルでは、ビジネスロジックっぽい項目が多いように感じるので、そういう使い方も期待してしまいます笑 開発内容が業務アプリよりだったりするので、視覚効果以外でReduxに依存しないコンポーネントの使い方が見つかると、面白いのですが・・・

Answer 2

コンポーネントのstateを使う必要がないのであれば、使わないに越したことはないのでは？
と思います。

Comments

[Meganezaru]

たしかに、その通りなのですが笑

ライブラリを書いた人には「こんな利用方法があるよ」というのが、何かしらあるんじゃないかな？とおもうんですよね。そういうことが気になる、知りたいという感じです。知見が広がると思いまして。

「理由を探す癖がある」ってところでしょうか・・・笑

[satoshih]

例えばですが、
とあるformにトグルボタンがあったとして、そのボタンの状態に応じて入力項目が変わる。
みたいな処理はコンポーネントのstateで持ってもいいかもしれないですね。

reducerで持つにしては細かすぎるので、、、

[Meganezaru]

ありがとうございます！

ひょっとすると、stateって外部から簡単に読み出せたりするんですかね？(^_^;)
簡単にできないと、思い込んでます・・・

入力項目をレンダリングする部分で、トグル状態を判断するイメージですよね。
stateが簡単に参照できるのであれば、狭い範囲で利用するのはありな気がしますね。

[satoshih]

stateは外部から取得はできない（やってはいけない）とおもいます。
ですので、状態を変化させたいコンポーネント全ての共通の先祖にstateを持たせる形になるんでしょうか

> とあるformにトグルボタンがあったとして、そのボタンの状態に応じて入力項目が変わる。
> みたいな処理はコンポーネントのstateで持ってもいいかもしれないですね。
この例だとformにstateが持てれないいですかね

[Meganezaru]

トグルのOff/On操作で、Formのstateを変更する方法がわからないので、
今なら、Reduxを選ぶかもしれません・・・formに、reducerを一つ割り当てちゃいます。笑

[satoshih]

親コンポーネントから子コンポーネントへ " stateを変更するメソッド" を`onChange` などで渡して、
子コンポーネントに変更があるとそのメソッドを実行して親コンポーネントのstateを変更するとかですかね

[Meganezaru]

なるほど、コールバックを引き継いで行けば、更新はできそうですね。
DIっていうのでしょうか？←よくわかってないかも・・・笑

規模の大きさによっては、stateで書いた方が、
コードが少なくなることはありそうですね。

少し理解できた気がします。ありがとうございました！