React:コンポーネントのライフサイクル

1.Reactのコンポーネント

ReactではUIを構成する要素のことをコンポーネント(Component)と呼びます。

具体的にはボタンやヘッダー、コンテナなどのことです。Reactで開発する利点としてはそれらのUIパーツをそれぞれ細かくコンポーネントに分けておくことで、再描画が必要なものだけに更新を走らせてパフォーマンスをチューニングができます。

2.コンポーネントのライフサイクル

ライフサイクルにはまず、大きく分けて3つの期間があります。

それぞれ順に

Mounting、Updating、Unmountingと呼ばれます。

2.1.Mounting

UIにコンポーネントが描画されるまでの準備期間。

使用できるメソッド:

• constructor()
• getDerivedStateFromProps()
• render()
• componentDidMount()

2.2.Updating

UIにコンポーネントが表示されていて、基本的にユーザーが操作できる期間。

使用できるメソッド:

• getDerivedStateFromProps()
• shouldComponentUpdate()
• render()
• getSnapshotBeforeUpdate()
• componentDidUpdate()

2.3.Unmounting

他のコンポーネントに切り替える前に現在のコンポーネントを破棄するための期間。

使用できるメソッド:

• componentWillUnmount()

3.ライフサイクルメソッド(基本編)

3.1.constructor()

Mounting時

JSXおよびTSXのフォーマットではまず見かけません。JavaScriptでReactを書く場合にstateの初期化やactionのバインドのために使用します。

3.2.componentDidMount()

Mounting時

1度目のrenderが呼ばれた後に1度だけ呼ばれるメソッドです。この時点ではまだUIに表示されていません。データをフェッチしたり、アニメーションやタイマーをセットする場合はここで行います。このメソッドからはDOMが作成されていますが、直接のDOM操作などライフサイクルを外れる処理は原則避けましょう。

3.3.render()

Mounting/Updating時

コンポーネントの根幹となる、一番呼ばれるかつ必須のメソッドです。ここに書いてあるコードが実際にUIに現れるものになります。

renderはpropsやstateが更新されるたびに呼ばれるため、ここで直接propsやstateを操作する処理を書いてはいけません。新しい関数を定義するのも避けましょう。そしてAPIのように、propsやstateの値が変わっても結果は冪等であるべきです。

※冪等：べきとうは、大雑把に言って、ある操作を1回行っても複数回行っても結果が同じであることをいう概念です

3.4.componentDidUpdate()

Updating時

第一引数に1つ前のprops、第二引数に1つ前のstate、第三引数にsnapshot(後述のgetSnapshotBeforeUpdateの返り値)が入ってきますが、必要なければ省略可能です。これもよく呼ばれるメソッドなため、パフォーマンスを低下させるpropsやstateを更新する処理は最低限にしましょう。また、if文や後述のshouldComponentUpdateで無駄な処理を避けることができます。

3.5.componentWillUnmount()

Unmounting時

現在のコンポーネントを破棄する直前に呼ばれるメソッドで、アニメーションやタイマーを設定していた場合はここで破棄します。そうしないと新しいコンポーネントのサイクルが始まった後も、その分のメモリが開放されないままになってしまいます。ちなみにもうrenderが呼ばれることはないので、ここでpropsやstateを変更しても意味がありません。

4.ライフサイクルメソッド(上級編)

4.1.getDerivedStateFromProps()

Mounting時

これだけはstaticです。第一引数に次のprops、第二引数に前のstateが入ってきます。propsの値によってstateの値を更新したい場合、propsが更新されてrender()が呼ばれる前にstateの更新が必要かどうかをチェックするメソッドです。更新があれば更新後のstate、なければnullを返します。

4.2.shouldComponentUpdate()

Updating時

第一引数に次のprops、第二引数に次のstateを持っており、前のpropsやstateの値やアドレスと比較し、変更がなければfalseを、あればtrueを返します。falseが返るとこのあとのrender()は呼ばれず再描画は行われません。PureComponentを使うと自動的にこの比較を行ってくれるため、自分で書くケースは稀ですが要のメソッドです。

4.3.getSnapshotBeforeUpdate()

Updating時

このメソッドの返り値はcomponentDidUpdateの第三引数に渡ります。具体例に挙げられているようなスクロール位置など、引き継ぎたい値がある場合に使います。

また上記に上げた以外で、エラーをハンドリングしたい場合はcomponentDidCatch()というメソッドが用意されています。

5.使用しないライフサイクルメソッド

補足として、React v16.2までで使用されていて、現在は使用を控えたほうがいいメソッドもここで上げておきます。古い資料ではこれらの記述がありますが、見かけても読み飛ばしてよいです。

5.1.getDefalutProps()

一度だけ呼ばれ、propsが渡されなかった場合に使う値を指定できます。constructorや、TypeScriptではデフォルト値を指定することで解決可能。

5.2.getInitialState()

Mounting時にまず呼ばれ、描画前にstateを変更するためのメソッド。TypeScriptではstateに初期値を指定できるので特に必要性を感じることはありません。

5.3.componentWillMount()

v16.3以降ではUNSAFE_componentWillMount()に改名されており、v17で完全に削除予定。1回目のrenderが呼ばれる直前に実行されます。

5.4.componentWillUpdate()

v16.3以降ではUNSAFE_componentWillUpdate()になっており、これもv17から削除予定です。使いたいと思ったら代わりにcomponentDidUpdate()やgetSnapshotBeforeUpdate()を使用すべき。

5.5.componentWillReceiveProps()

v16.3以降ではUNSAFE_componentWillReceiveProps()で、v17から削除予定。componentDidUpdate()またはgetDerivedStateFromProps()で代用できます。

React:開発手順

 1.準備

簡単なデザインと、JSONデータを準備する。
設計書もよいが、テスト駆動型でかつアジャイルで開発するほうが、よりよいものができる

2.UI をコンポーネントの階層構造にする

モックを形作っている各コンポーネント（構成要素）を四角で囲んで、それぞれに名前をつけていくことです。

JSON のデータモデルをユーザに向けて表示することはよくありますので、モデルを正しく構築されていれば、UI（つまりコンポーネントの構造）にもうまくマッピングされるということが分かるでしょう。これは、UI とデータモデルが同じ 情報の構造 を持つ傾向があるためです。UI を分割して、それぞれのコンポーネントがデータモデルの厳密に一部分だけを表現するよう、落とし込みましょう。

5 種類のコンポーネントがこのアプリの中にあることが見て取れます。

1. FilterableProductTable（オレンジ色）： このサンプル全体を含む
2. SearchBar（青色）： すべてのユーザ入力を受け付ける
3. ProductTable（緑色）： ユーザ入力に基づくデータの集合を表示・フィルタする
4. ProductCategoryRow（水色）： カテゴリを見出しとして表示する
5. ProductRow（赤色）： 各商品を 1 行で表示する

ProductTable を見てみると、表のヘッダ（「Name」や「Price」のラベルを含む）が単独のコンポーネントになっていないことがわかります。

これは好みの問題で、コンポーネントにするかしないかは両論あります。今回の例でいえば、ヘッダを ProductTable の一部にしたのは、データの集合を描画するという ProductTable の責務の一環として適切だったからです。

しかしながら、将来ヘッダーが肥大化して複雑になった場合（例えばソート機能を追加した場合など）は、ProductTableHeader のようなコンポーネントにするのが適切になるでしょう。

さて、モック内にコンポーネントを特定できましたので、階層構造に並べてみましょう。モックで他のコンポーネントの中にあるコンポーネントを、階層構造でも子要素として配置すればいいのです。次のようになります。

• FilterableProductTable
• SearchBar
• ProductTable
• ProductCategoryRow
• ProductRow

3.Reactで静的なバージョンを作成する

データモデルを描画するだけの機能を持った静的なバージョンのアプリを作る際には、他のコンポーネントを再利用しつつそれらに props を通じてデータを渡す形で、自分のコンポーネントを組み上げます。

props は親から子へとデータを渡すための手段です。

state はユーザ操作や時間経過などで動的に変化するデータを扱うために確保されている機能です。今回のアプリは静的なバージョンなので、state は必要ありません。

コンポーネントはトップダウンで作っても、ボトムアップで作っても問題ありません。

つまり、高い階層にあるコンポーネント（例えば FilterableProductTable）から作り始めても、低い階層にあるコンポーネント（ProductRow など）から作り始めても、どちらでもいいのです。シンプルなアプリでは通常トップダウンで作った方が楽ですが、大きなプロジェクトでは開発をしながらテストを書き、ボトムアップで進める方がより簡単です。

ここまでのステップを終えると、データモデルを描画する再利用可能なコンポーネントのライブラリが手に入ります。このアプリは静的なバージョンなので、コンポーネントは render() メソッドだけを持つことになります。

階層構造の中で最上位のコンポーネント（FilterableProductTable）が、データモデルを props として受け取ることになるでしょう。元となるデータモデルを更新して再度 ReactDOM.render() を呼び出すと、UI が更新されることになります。このやり方なら、複雑なことをしていないので、UI がどのように更新されて、どこを変更すればよいか、理解できることでしょう。React の単方向データフロー（あるいは単方向バインディング）により、すべてがモジュール化された高速な状態で保たれます。

4.UI 状態を表現する state を決定

UI をインタラクティブなものにするためには元となっているデータモデルを更新できる必要があります。これは React なら state を使うことで実現できます。

適切に開発を進めていくにあたり、そのアプリに求められている更新可能な状態の最小構成を、最初に考えておいたほうがよいでしょう。

ここで重要なのは、DRY (don’t repeat yourself)の原則です。アプリケーションが必要としている最小限の状態を把握しておき、他に必要なものが出てきたら、そのとき計算すればよいのです。

例えば、TODO リストを作る場合、TODO の各項目を配列で保持するだけにし、個数のカウント用に別の state 変数を持たないようにします。その代わりに、TODO の項目数を表示したいのであれば、配列の length を使えばよいのです。

今回は、次のようなデータがあるとする

• 元となる商品のリスト
• ユーザが入力した検索文字列
• チェックボックスの値
• フィルタ済みの商品のリスト

それぞれについて見ていき、どれが state になりうるのかを考えてみます。

各データについて、考えましょう。

• 親から props を通じて与えられたデータでしょうか？
  もしそうなら、それは state ではありません
• 時間経過で変化しないままでいるデータでしょうか？
  もしそうなら、それは state ではありません
• コンポーネント内にある他の props や state を使って算出可能なデータでしょうか？ もしそうなら、それは state ではありません

例で考えると

• 元となる商品のリストは props から渡されるので、これは state ではありません。
• 検索文字列とチェックボックスは時間の経過の中で変化し、また、算出することもできないため、state だと思われます。
• 最後に、フィルタ済みの商品のリストは state ではありません。何故ならば、元となる商品のリストと検索文字列とチェックボックスの値を組み合わせることで、フィルタ済みの商品のリストを算出することが可能だからです。

というわけで、state と呼べるのは次の 2 つです。

• ユーザが入力した検索文字列
• チェックボックスの値

5.state をどこに配置すべきか

アプリの各 state について、次の各項目を確認していきます。

• その state を使って表示を行う、すべてのコンポーネントを確認する
• 共通の親コンポーネントを見つける（その階層構造の中で、ある state を必要としているすべてのコンポーネントの上位にある単一のコンポーネントのことです）
• 共通の親コンポーネントか、その階層構造でさらに上位の別のコンポーネントが state を持っているべきである
• もし state を持つにふさわしいコンポーネントを見つけられなかった場合は、state を保持するためだけの新しいコンポーネントを作り、階層構造の中ですでに見つけておいた共通の親コンポーネントの上に配置する

それでは、例に適用してみましょう。

• ProductTable は商品リストをフィルタする必要があり、SearchBar は検索文字列とチェック状態を表示する必要がある
• 共通の親コンポーネントは FilterableProductTable である
• 概念的にも、検索文字列とチェック状態が FilterableProductTable に配置されることは妥当である

state を FilterableProductTable の中に配置することが決まりました。では早速、インスタンス変数として this.state = {filterText: '', inStockOnly: false} を FilterableProductTable の constructor に追加して、初期状態をアプリに反映しましょう。その次は、filterText と inStockOnly を ProductTable と SearchBar に props として渡します。最後に、これらの props を使って ProductTable のフィルタ処理を行い、SearchBar のフォームにも値を埋めます。

6.逆方向のデータフローを追加

現在のバージョンのサンプルで文字を打ち込んだり、チェックボックスを切り替えてみると、React がその入力を無視することがわかります。これは意図的な挙動で、input の value props が、常に FilterableProductTable から渡された state と同じ値になるようにセットしてあるのです。

それでは、どんな挙動になってほしいのかを考えてみましょう。ユーザがフォームを変更するたびに、ユーザ入力を反映するように state を更新したいですね。コンポーネントの state を更新できるのは自分自身だけであるべきなので、FilterableProductTable は SearchBar にコールバックを渡しておいて、state を更新したいときに実行してもらうようにします。入力のたびに呼び出される onChange イベントを利用するとよいでしょう。このコールバックを実行された FilterableProductTable は、setState() を呼び出し、その結果としてアプリが更新されます。

React:デザインパターン

1.デザインパターンの重要性

デザインパターンとは、ソフトウェア開発において一般的に発生する問題に対する反復可能な解決策のことです。

デザインパターンは基本的なテンプレートとして機能し、与えられた要求に応じてプログラムの機能を構築することができます。

デザインパターンは、開発プロセスを高速化するだけでなく、コードの読みやすさやメンテナンスのしやすさを向上させます。

デザインパターンの一般的な例としては、SingletonパターンやGang-of-Fourパターンなどがあります。

ソフトウェア開発において、デザインパターンには2つの共通した役割があります。

• 開発者に共通のプラットフォームを提供する

デザインパターンは、標準的な用語や既知の問題に対する解決策を提供する。

• ベストプラクティスの確保

デザインパターンは、広範な研究とテストの結果として作成されています。デザインパターンは、開発者が開発環境に容易に慣れることができるだけでなく、ベストプラクティスが守られていることを保証します。

その結果、エラーが少なくなり、適切なデザインパターンが実装されていれば簡単に回避できたであろう問題のデバッグや解明にかかる時間を節約することができます。

2.Reactjsの機能

reactは、Githubで公開されているcreate-react-appを使ってインストールできます。npmを使用すると、他のすべての依存関係を追加できます。

React.jsは、JSXを利用しています。これは、JavaScriptの構文拡張です。JavaScriptのフルパワーを備えており、Reactの「要素」と呼ばれるものを提供してくれます。

JSXの使用は必須ではありませんが、JSXが提供する便利な視覚支援とスタイリングオプションのため、好ましい方法です。また、有用なエラーメッセージや警告も表示されます。

React.jsの基本理念は、再利用可能なリアクトコンポーネントです。このコンポーネントベースのアプローチは、Webアプリケーションのリッチなユーザーインターフェースを構築するために活用できることがわかります。

これらのReactコンポーネントは、それ自体が小さなシステムであると考えることができます。各コンポーネントは、独自の状態、入力、出力を持ちます。

コンポーネントの入力は、プロップの形で取得されます。コンポーネントは、ブラックボックスと考えることができます。それぞれが独自の状態とライフサイクルを持っています。コンポーネントは簡単に構成することができます。

最終的なReactアプリは、保守性の高いコードで構成されています。

3.Reactのデザインパターン

3.1.ステートレスコンポーネント

ステートとは、コンポーネントにインポートされるデータのことです。通常、データはデータベースから取得されます。

コンポーネントには、ステートフルコンポーネントとステートレスコンポーネントという2つのタイプがあります。両者の違いは、単にステートがあるかないかだけです。

ステートレスコンポーネントでは、その内部でthis.stateに到達することはできません。

ステートレスコンポーネントは、機能的コンポーネントや提示的コンポーネントとも呼ばれます。Reactでは、このようなコンポーネントは常に同じものをレンダリングするか、propsで渡されたものだけをレンダリングします。

開発者としての目的は、たとえその特定のコンポーネントを再利用しなければならないシナリオがすぐになくても、ステートレスコンポーネントを作成することです。

多くの場合、開発者は、あるコンポーネントが状態を持つ必要があるかどうかを、コードを書き始めてから理解しますが、それは必ずしも事前に明確ではないからです。

階層構造のコンポーネントでは、親コンポーネントにできるだけ多くの状態を保持させ、ステートレスな子コンポーネントを作るのがベストな方法です。データの受け渡しはプロップで行います。

3.2.条件付きレンダリング

条件はソフトウェア開発者の武器の中で最も重要なツールです。

Reactコンポーネントを作成する過程で、状態に応じて特定のJSXコードをレンダリングする必要が生じることがよくあります。これを実現するのが、条件付きレンダリングです。

条件付きレンダリングは、ニーズに応じて個別のコンポーネントを作成し、アプリケーションに必要なものだけをレンダリングすることができるので、非常に便利です。

例えば、条件付きレンダリングを使って、ユーザーのログイン状態に応じて異なるメッセージをユーザーに表示することができます。メッセージは、 isLoggedIn  というプロップの値に従います。

3.3.レンダリングプロップ

デザインパターンが共通の問題を解決するために存在することを説明しました。Reactでは、ロジックの繰り返しの問題を解決するためにRenderプロップが用意されています。

Reactの公式ドキュメントによると、レンダープロップは「値が関数であるプロップを使ってReactコンポーネント間でコードを共有するためのテクニック」と定義されています。

レンダープロップは、異なるコンポーネント間で同じ状態を共有することができるため、非常に便利なものです。各コンポーネント内のロジックをハードコーディングする代わりに、何をレンダリングするかを決定するために関数プロップを使用することができます。

Formik、React Router、Downshiftなど、レンダープロップを利用した人気のあるライブラリがあります。

3.4．制御されたコンポーネント

Webフォームは多くのアプリケーションで共通の要件であり、制御されたコンポーネントはフォームの状態を処理するためのReactの答えです。

コントロールされたコンポーネントは、プロップを通して状態を受け取ります。それは  onChange のようなコールバックによって変更を通知することができます。 親コンポーネントは、コールバックを処理し、自身の状態を管理することで、コントロールされたコンポーネントを制御することができ、その間、新しい値はコントロールされたコンポーネントにpropsとして渡されます。デフォルトでは、Reactフォームは制御されたコンポーネントと制御されていないコンポーネントの両方をサポートしています。制御されたコンポーネントを使用することを強くお勧めします。

次のコードスニペットは、制御されたコンポーネントを示しています。

<input type = "text" value = {value} onChange = {handleChange} />    

3.5.Reactのフック

フックはReactの比較的新しい追加機能で、React 16.8で導入されました。

これらの機能により、開発者はクラスなしでReactを使用することができます。Effect Hook ( useEffect ) や State Hook など、さまざまなフックがあらかじめ用意されています。

利用可能なフックの完全なリストについては、 Hooks API Reference  を参照してください。 Reactにあらかじめ用意されているフックとは別に、独自のフックを作成することもできます。これにより、コンポーネントのロジックを抽出し、再利用可能な関数を作成することができます。

フックはReactの歓迎すべき機能であり、開発者コミュニティはこの新しい機能を非常に熱心に評価しています。

しかし、フックの引数がオブジェクト、配列、関数である場合には、フックの扱いが少し難しくなることがあることを覚えておく必要があります。これでは少々混乱してしまいます。

一方で、カスタムフックは簡単で使いやすく、開発者にとっても大きなメリットがあります。

React:React

1.Reactとは 

JavaScript フロントエンドフレームワーク

アプリケーションで各状態に対するシンプルな設計をすることで、React はデータが変更された時に、適切なコンポーネントだけを効率的に更新してレンダリングすることができる

自身の状態を管理するカプセル化されたコンポーネントを構築することで、それらのコンポーネントを呼び出し複雑なUI もコンポーネント呼び出しで作成できる

2.Reduxとは

Fluxアーキテクチャの一種

2.1.構成用要素

2.1.1.Reduce

状態を変化させる関数

引数

store        今の状態を示すオブジェクト

action        どんな動作を行ったかを示すオブジェクト

ES2015仕様：Spread Operator

const hoge = [2, 3];

console.log(1, ...hoge, 4.5);

// 実行結果　[1,2,3,4,5]

const fuga = { name: 'Taro', age: 25 };

const piyo = { name: 'Jiro', location: 'Tokyo' };

console.log({ ...fuga, ...piyo });

// プロパティがかぶる場合、後のものが優先する

// 実行結果　{name: 'Jiro',age: 25 ,location: 'Tokyo' }

const myFunc = (x, y, z) => [x, y, z];

const age = [0, 1, 2];

mfFunc(...age);

// 実行結果　[0,1,2]

注意点

値渡が基本　オブジェクトや配列は参照渡しとなるため、Object.assignを用いる

onst target = { a: 1, b: 2}

const source = { b: 3, d: 4}

const returnedTarget = Object.assign(target, source);

console.log(target);

console.log(source);

console.log(returnedTarget);

// $ node test.js

// { a: 1, b: 3, d: 4 }

// { b: 3, d: 4 }

// { a: 1, b: 3, d: 4 }

let user = {

    username: "John",

};

let user_id = {

    id: 1,

};

let email = {

    email: "john@example.com",

};

user = Object.assign(user, user_id, email);

console.log(user);

  //結果

  //{ username: 'John', id: 1, email: 'john@example.com' }

Object.assignを使った例(form)

const form = {

    firstName: null,

    lastName: null,

    Email: null,

    zipCode: null,

    Address: null,

    Phone: null

}

const input = {

    firstName: 'John',

    lastName: 'Doe',

    Email: 'john@example.com'

}

Object.assign(form, input)

console.log(form)

// $ node test.js

//  {

//  firstName: 'John',

//  lastName: 'Doe',

//  Email: 'john@example.com',

//  zipCode: null,

//  Address: null,

//  Phone: null

// }

JS:Atomic Design

1.Atomic Designのコンポーネント

Atomic Designで有名なのは、UIの構造を次の5段階で考える

• Atoms（原子）
• Molecules（分子）
• Organisms（有機体）
• Templates（テンプレート）
• Pages（ページ）

あらゆるものが原子の集まりでできているように、ページもAtoms（原子）の集まりであると考え、Atomsが組み合わさってMolecules（分子）になり、Molecules（分子）が組み合わさってOrganisms（有機体）となる。

Organisms（有機体）の集まりでページのフレームであるTemplates（テンプレート）を作るが、このTemplatesは具体的なコンテンツの入っていない空っぽのページの枠組み。そこに具体的なテキストや画像を入れ込んでPages（ページ）を作る……というふうに、UIを階層構造で考えます。

1.1.Atoms（原子）の例

Atomsの例は、検索フォームのパーツです。ここでは「ラベル」「テキスト入力欄」「ボタン」というように、これ以上分けられないような単位のUIをAtomとしています。

1.2.Molecules（分子）の例

「ラベル」「テキスト入力欄」「ボタン」といったAtomを組み合わせて作った「検索フォーム」がMoleculeです。

1.3.Organisms（有機体）の例

そして、この「検索フォーム」やその他「メニュー」や「サイトのロゴ」など、他のMoleculeらが集まってできている「ヘッダ」がOrganismです。

1.4.Templates（テンプレート）の例

Organismを組み合わせ、ページの枠組みを構成します。ただ中身はすべてダミーです。これがTemplate。

1.5.Pages（ページ）の例

Templateに具体的なコンテンツを入れ込んだのが、最終的なアウトプットとなるPageです。

このように、UIを分解して考え、他の画面でも共通で使えるAtom、Moleculeをどう設計するか、細部を作りながら全体を俯瞰し、また細部が適切かどうか、具体的にコンテンツを入れながら考えるというのが、Atomic DesignのUIデザイン方法論です。

このようにしてUIを考え、サイト全体として共通のUIライブラリを作り上げます。