Reactに入門しましたが、「コンポーネント指向」「コンポーネントの責務」「コンポーネントのカプセル化」などなど。
「コンポーネント」というキーワードをよく使います。
そもそも「コンポーネント」についてしっかり調べようと思いました。
コンポーネントとは
javascriptの関数と似ている。
任意のデータ(props)を受け取り、画面を構成するReact要素を返す。
UIを独立したコンポーネントに分割することで、部品として再利用できるようになる。
また、それぞれの部品を分離して考えることができる。（新しい部品を追加しても影響を受けない）
コンポーネントはロジックと見た目をあわせもったもの。関数のようにロジック機能があり、React要素を返すことで見た目を作り出している。
コンポーネント指向（コンポーネントベース）
Reactの3つの特徴の一つに「コンポーネントベース」がある。
自分自身の状態を管理するカプセル化されたコンポーネントをまず作成し、これらを組み合わせることで複雑なユーザインターフェイスを構築します
参考URL：https://ja.reactjs.org/
カプセル化されたコンポーネント？
カプセル化の目的はコンポーネントを保護にある。
コンポーネントの変更はStateなどの状態に任せることで、コンポーネントの不正な変更を防ぐことができる。これによってバグ（不整合）を回避する。
カプセル化を壊すことはおすすめしない
DOM の Ref を親コンポーネントに公開する
まれに、親コンポーネントから子コンポーネントの DOM ノードにアクセスしたい場合があります。これは、コンポーネントのカプセル化を壊すため、一般的にはおすすめできませんが、フォーカスを発火させたり、子の DOM ノードのサイズや位置を計測するのに役立つことがあります。
参考URL：https://ja.reactjs.org/docs/refs-and-the-dom.html
- フォーカスを発火
- 子のDOMノードのサイズや位置の計測
Reactでは、これらの例以外での使用はおすすめしてない。
使用は限定的にすることで、コンポーネントの不正な変更を防ぐことができる。
React 16.3 以降を使用している場合、これらの場合には
ref のフォワーディング を使用することをおすすめします。
Ref のフォワーディングを使うと、コンポーネントは任意の子コンポーネントの ref を自分自身の ref として公開できるようになります。
親が子コンポーネントにアクセスする場合は、Refのフォワーディングを推奨。（React 16.3以降）
getElementById()を使うこともカプセル化を壊すのでは？
getElementById()は使えるが・・・
使う場所や用途に気を付ける必要がある。
- 仮想DOMでidを使うとレンダリング時にid名が被る可能性がある
- DOMを直接操作するのでstateに関係なく書き換えができてしまう（カプセル化を壊す）
これらの理由でバグの温床になるのではないかと考える。
レンダー先のコンテナの指定くらいにとどめて、あまり使うべきではなさそう。
単一責任の原則
Reactの流儀の中で、 UI をコンポーネントの階層構造に落とし込む際には単一責任の原則が理想とされている。
これは、コンポーネントの変更理由（状態）は一つであることが理想的であるということ。コンポーネントが変更される場合はそのコンポーネントの状態を変更することになる。
つまり、他のコンポーネントがあるコンポーネントを変更したい場合は、コンポーネントにアクセスするのではなく、そのコンポーネントの状態を変更して渡すことになると考える。
ひとつのコンポーネントは理想的にはひとつのことだけをするべきだということです。将来、コンポーネントが肥大化してしまった場合には、小さなコンポーネントに分割するべきです。
参考URL：https://ja.reactjs.org/docs/thinking-in-react.html#step-1-break-the-ui-into-a-component-hierarchy
コンポーネントは小さく
小さなコンポーネントに分割されていれば、コンポーネントの責務も小さくなる。
確認すべきコードも短くなるので、管理面でのメリットがある。
注意しなくていけにことは、コンポーネントの粒度は開発者によって異なること。すり合わせをしていく必要がある。
参考