こんにちは、今回はReactの基礎についてざっくりまとめてみました!
Reactの思想
- Don't touch the DOM. I'll do it.
- Build websites like lego blocks.
- Unidirectional data flow.
- UI, The rest is up to you.
JSXとは
JavaScriptを拡張してHTMLのような形式で書けるコードのこと。HTML形式ではあるものの、あくまでもHTML形式のJSコードのため、区別が必要。htmlでいうところのclassなどもJSXでは className のような形式で記述する。基本的にプロパティは既述の className のようにキャメルケースで記載する。
React Scripts
- react-script start → ローカルの環境上で実行しますよ。ってやつ。
- react-script build → BabelとWebpackを使用してオンラインで公開できるようにファイル作成しますよ。ってやつ。
- react-script eject →
Babel と Webpack
Reactをする上で必要となるものがBabelとWebpack。
BabelはJSXなどのコードをブラウザで読み込めるようなJSにコンパイルしてくれるツール。Reactを使用すると、importなどでファイルを読み込むことが多いが、webpackはそのようなimportなどを芋づる式に辿り、整理してJSファイルを出力してくれる。
React開発について
React開発の時に意識すると良いこと。
・いつ renderingされて
・いつ re-renderingされるか
を意識すると、開発する時に非常に有用とのこと。
コンポーネント(Components)
Reactにとってコンポーネントという概念は非常に重要。Reactの開発においては、基本的にコンポーネント(部品)単位で開発を進めていくことになる。
コンポーネントには
- 関数コンポーネント(functional component)
- クラスコンポーネント(class component)
の2種類がある。
関数コンポーネントに関しては、基本的に関数のような記載になるので表示する要素などに関しては return で返すような構造になっている。state を持たないコンポーネントをシンプルに書く方法として適している。
クラスコンポーネントに関しては、classを使用して記載していき、renderのような形で要素を表示するような構造になっている場合が多い。
ステート、状態(States)
Reactで開発する上で欠かせないのが状態(state)管理。Statesは基本的にはjson形式になっている。stateがあることによってコンポーネントが情報を保持できるようになる利点がある。
stateの更新、変更は setState で行う。setStateによってStateが更新されるとそのコンポーネントは再レンダリングされる。(setStateには、stateの更新だけでなく、再レンダリングも行ってくれる。)setStateでのマージ方法はshallow merge(浅いマージ)で行われる。
setStateは非同期で行われるため、setStateの後に記載するコードが必ずしもstateが変更された後に実行されるわけではない。もしsetStateでstateの変更をおこなった後に実行したい処理がある場合は
this.setState(
() => {
return {
①Stateの変更処理
}
},
() => {
②State変更後に実行したい処理
}
)
のように書くと①の後に②が実行される。
stateは、そのstateが定義されているコンポーネントにおいて、ぷらいべーとなものなので、例えば親コンポーネントの state は、子コンポーネントから直接変更できない。
プロパティ(Props)
親コンポーネントから子コンポーネントに値を渡す時に使用するのが Props。Reactはコンポーネントをもとに設計されるため、親コンポーネントで使用している値を子コンポーネントで使用したい場合が度々出てくる。属性を保管するという意味でも、使用される。
このPropsは基本的にread-onlyで参照用で使用され、値を取り出すことができる一方で書き換えはできないなどの一方向性の特徴を持つ。
propsは基本的に { } の波括弧内で渡される。
イベントを表す props には、on[Event] のような名前を付けて、イベントを処理するメソッドには handle[Event] のような命名規則を適用することが多い。例えばクリックに関するイベントであれば
onClick = { () => this.handleClick(i) }
のように名前をつける。
State と Props の活用
基本的に大元のコンポーネントに State を持たせるのがベストプラクティス。そして、更新した state の情報は子コンポーネントに props として渡していくのが好ましい。
ただ既述の通り、state はそのコンポーネント内においてプライベートなものなので、子コンポーネントから直接変更することはできない。
なので、子コンポーネントから親コンポーネントの state を変更させたい場合は変更用の関数を親コンポーネントで用意して、その変更用関数を子コンポーネントから呼び出すようにする。
(親コンポーネント)→ state, state更新用の関数を用意 & 子コンポーネントにstate更新用関数を渡す
(子コンポーネント)→ state を変更する際は、stateの更新関数を実行して親コンポーネントのstateを更新する
Stateのリフトアップ
Stateは既述の通り、コンポーネント内でしか直接変更することができないプライベートなものであることは既に述べた。
『子コンポーネント が 親コンポーネントの state にアクセスしたい』
という場面はあるが state が子コンポーネントにある場合に
『親コンポーネント が 子コンポーネントの state にアクセスしたい』
という場面にも出くわす。
結論として、親コンポーネントから子コンポーネントのstateを参照することはできなくないが、コードが複雑になったりして好ましくない。
なので、その際は子コンポーネントにある state をもう一つ上のコンポーネントに引き上げる(リフトアップする)ということが行われる。結構頻繁にある作業なので、書き留めておく。
Immutability (不変性 or 非破壊性)のすすめ
データ変更時の方法として、元データを直接変更する(mutability:可変性 or 破壊性)と元データをコピーしてコピーしたものを変更、元データと置換する(immutability:不変性 or 非破壊性)の2つの方法が考えられる。
React では、基本的にimmutableな変更を推奨している。
その理由としてReact公式ドキュメントでは
- 複雑な機能が簡単に実装できる
- 変更の検出がしやすい
- 再レンダーリングの決定
https://ja.reactjs.org/tutorial/tutorial.html#why-immutability-is-important
という利点が挙げられている。