Reactのコンセプトを理解する

基本講座の最後として、検索可能な商品データ表を React で作っていく様子をお見せします。 モックから始めよう すでに、JSON API が実装済みで、デザイナーからもデザインモックがもらえているとしましょう。モックは次のような見た目だったとします。 また、JSON API は次のようなデータを返してくるとしましょう。 Step 1: UI をコンポーネントの階層構造に落とし込む まず最初に行うのは、モックを形作っている各コンポーネント（構成要素）を四角で囲んで、それぞれに名前をつけていくことです。もしあなたがデザイナーと一緒に仕事をしている場合は、彼らがすでにこれに相当する作業を終えている可能性がありますので、話をしに行きましょう。彼らが Photoshop でレイヤ名にしていた名前が、最終的にはあなたの React コンポーネントの名前になりうるのです！ しかし、どうやって単一のコンポーネントに括るべき範囲を見つけられるのでしょうか。ちょうど、新しい関数やオブジェクトをいつ作るのかを決めるときと、同じ手法が使えます。このような手法のひとつに、単一責任の原則 (single responsibility principle) があり、これはすなわち、ひとつのコンポーネントは理想的にはひとつのことだけをするべきだということです。将来、コンポーネントが肥大化してしまった場合には、小さなコンポーネントに分割するべきです。 JSON のデータモデルをユーザに向けて表示することはよくありますので、モデルを正しく構築されていれば、UI（つまりコンポーネントの構造）にもうまくマッピングされるということが分かるでしょう。これは、UI とデータモデルが同じ 情報の構造 を持つ傾向があるためです。UI を分割して、それぞれのコンポーネントがデータモデルの厳密に一部分だけを表現するよう、落とし込みましょう。 5 種類のコンポーネントがこのアプリの中にあることが見て取れます。それぞれの解説の中で、データを表すものについては太字にしました。図中の番号は以下の番号と対応しています。 ProductTable を見てみると、表のヘッダ（「Name」や「Price」のラベルを含む）が単独のコンポーネントになっていないことがわかります。これは好みの問題で、コンポーネントにするかしないかは両論あります。今回の例でいえば、ヘッダを ProductTable の一部にしたのは、データの集合を描画するという ProductTable の責務の一環として適切だったからです。しかしながら、将来ヘッダーが肥大化して複雑になった場合（例えばソート機能を追加した場合など）は、ProductTableHeader のようなコンポーネントにするのが適切になるでしょう。 さて、モック内にコンポーネントを特定できましたので、階層構造に並べてみましょう。モックで他のコンポーネントの中にあるコンポーネントを、階層構造でも子要素として配置すればいいのです。次のようになります。 Step 2: Reactで静的なバージョンを作成する さて、コンポーネントの階層構造が決まったので、アプリの実装に取り掛かりましょう。最初は、データモデルを受け取って UI の描画だけを行い、ユーザからの操作はできないというバージョンを作るのが、もっとも簡単でしょう。表示の実装とユーザ操作の実装を切り離しておくことは重要です。静的な（操作できない）バージョンを作る際には、タイプ量が多い代わりに考えることが少なく、ユーザ操作を実装するときには、考えることが多い代わりにタイプ量は少ないからです。なぜそうなのかは後で説明します。 データモデルを描画するだけの機能を持った静的なバージョンのアプリを作る際には、他のコンポーネントを再利用しつつそれらに props を通じてデータを渡す形で、自分のコンポーネントを組み上げていきましょう。props は親から子へとデータを渡すための手段です。もし、あなたが state に慣れ親しんでいる場合でも、今回の静的なバージョンを作る上では一切 state を使わないでください。state はユーザ操作や時間経過などで動的に変化するデータを扱うために確保されている機能です。今回のアプリは静的なバージョンなので、state は必要ありません。 コンポーネントはトップダウンで作っても、ボトムアップで作っても問題ありません。つまり、高い階層にあるコンポーネント（例えば FilterableProductTable）から作り始めても、低い階層にあるコンポーネント（ProductRow など）から作り始めても、どちらでもいいのです。シンプルなアプリでは通常トップダウンで作った方が楽ですが、大きなプロジェクトでは開発をしながらテストを書き、ボトムアップで進める方がより簡単です。 ここまでのステップを終えると、データモデルを描画する再利用可能なコンポーネントの一式が手に入ります。このアプリは静的なバージョンなので、コンポーネントは render() メソッドだけを持つことになります。階層構造の中で最上位のコンポーネント（FilterableProductTable）が、データモデルを props として受け取ることになるでしょう。元となるデータモデルを更新して再度 root.render() を呼び出すと、UI が更新されることになります。このやり方なら、複雑なことをしていないので、UI がどのように更新されて、どこを変更すればよいか、理解できることでしょう。React の単方向データフロー（あるいは単方向バインディング）により、すべてがモジュール化された高速な状態で保たれます。 ヒント：Props vs State React には 2 … Read more

React は強力なコンポジションモデルを備えており、コンポーネント間のコードの再利用には継承する方法よりもコンポジションをお勧めしています。 この章では、React を始めて間もない開発者が継承に手を出した時に陥りがちないくつかの問題と、コンポジションによりその問題がどのように解決できるのかについて考えてみます。 子要素の出力 (Containment) コンポーネントの中には事前には子要素を知らないものもあります。これは Sidebar や Dialog のような汎用的な “入れ物” をあらわすコンポーネントではよく使われています。 このようなコンポーネントでは特別な children という props を使い、以下のようにして受け取った子要素を出力することができます。 これにより他のコンポーネントから JSX をネストすることで任意の子要素を渡すことができます。 <FancyBorder> JSX タグの内側のあらゆる要素は FancyBorder に children という props として渡されます。FancyBorder は <div> の内側に {props.children} をレンダーするので、渡された要素が出力されます。 あまり一般的ではありませんが、複数の箇所に子要素を追加したいケースも考えられます。そのようなケースでは以下のように children の props の代わりに独自の props を作成して渡すことができます。 <Contacts /> や <Chat /> のような React の要素はただのオブジェクトなので、他のあらゆるデータと同様に props として渡すことができます。このアプローチは他のライブラリで言うところの slot に似ていると感じるかもしれませんが、React のコンポーネントに props として渡せるものに制限はありません。 特化したコンポーネント (Specialization) コンポーネントを他のコンポーネントの “特別なケース” として考えることがあります。例えば、WelcomeDialog は Dialog の特別なケースがあります。 React ではこれもコンポジションで実現できます。汎用的なコンポーネントに props を渡して設定することで、より特化したコンポーネントを作成することができます。 コンポジションはクラスとして定義されたコンポーネントでも同じように動作します。 継承はどうなの？ Facebook では、何千というコンポーネントで React を使用していますが、コンポーネント継承による階層構造が推奨されるケースは全く見つかっていません。 props とコンポジションにより、コンポーネントの見た目と振る舞いを明示的かつ安全にカスタマイズするのに十分な柔軟性が得られます。コンポーネントはどのような props でも受け付けることができ、それはプリミティブ値でも、React … Read more

しばしば、いくつかのコンポーネントが同一の変化するデータを反映する必要がある場合があります。そんなときは最も近い共通の祖先コンポーネントへ共有されている state をリフトアップすることを推奨します。これを、実際にはどのように行うかを見てみましょう。 この章では、与えられた温度で水が沸騰するかどうかを計算する温度計算ソフトを作成します。 BoilingVerdict というコンポーネントから始めましょう。これは温度を celsius という props として受け取り、水が沸騰するのに十分な温度かどうかを表示します。 次に Calculator と呼ばれるコンポーネントを作成します。温度を入力するための <input> 要素をレンダーし、入力された値を this.state.temperature に保持します。 加えて、現在の入力値を判定する BoilingVerdict もレンダーします。 2 つ目の入力を追加する 新しい要件は、摂氏の入力に加えて、華氏の入力もできるようにして、それらを同期させておくことです。 Calculator から TemperatureInput コンポーネントを抽出するところから始めましょう。props として、”c” もしくは “f” の値をとる scale を新しく追加します： これで Calculator を 2 つの別個の温度入力フィールドをレンダーするように変更することができます： 2 つの入力フィールドが用意できました。しかし、片方に温度を入力しても、もう片方は更新されません。これは要件を満たしていません： 2 つの入力フィールドを同期させたいのです。 Calculator から BoilingVerdict を表示することもできません。Calculator は TemperatureInput の中に隠されている現在の温度を知らないのです。 変換関数の作成 まず、摂氏から華氏に変換するものとその反対のものと、2 つの関数を書きます。 これら 2 つの関数は数字を変換します。次に文字列で表現された temperature と変換関数を引数に取り文字列を返す、別の関数を作成します。この関数を一方の入力の値をもう一方の入力に基づいて計算するのに使用します。 常に値が小数第 3 位までで四捨五入されるようにし、無効な temperature には空の文字列を返します。 例えば、tryConvert(‘abc’, toCelsius) は空の文字列を返し、tryConvert(‘10.22’, toFahrenheit) は ‘50.396’ を返します。 state のリフトアップ 現時点では、両方の TemperatureInput コンポーネントは独立してローカルの state を保持しています： しかし、2 つの入力フィールドはお互いに同期されていて欲しいのです。摂氏の入力フィールドを更新したら、華氏の入力フィールドも華氏に変換された温度で反映されて欲しいですし、逆も同じです。 React での state の共有は、state を、それを必要とするコンポーネントすべての直近の共通祖先コンポーネントに移動することによって実現します。これを “state のリフトアップ (lifting state up)” と呼びます。TemperatureInput からローカルの state を削除して Calculator に移動しましょう。 Calculator が共有の … Read more

HTML のフォーム要素は当然のこととして内部に何らかの状態を持っていますので、フォーム要素は React において他の DOM 要素と少し異なる動作をします。例えば、この HTML によるフォームは 1 つの名前を受け付けます： このフォームは、ユーザがフォームを送信した際に新しいページに移動するという、HTML フォームとしてのデフォルトの動作をします。React でこの振る舞いが必要なら、そのまま動きます。しかし大抵のケースでは、フォームの送信に応答してユーザがフォームに入力したデータにアクセスするような JavaScript 関数があった方が便利ですね。これを実現する標準的な方法は、“制御された (controlled) コンポーネント” と呼ばれるテクニックを使うことです。 制御されたコンポーネント HTML では <input>、<textarea>、そして <select> のようなフォーム要素は通常、自身で状態を保持しており、ユーザの入力に基づいてそれを更新します。React では、変更されうる状態は通常はコンポーネントの state プロパティに保持され、setState() 関数でのみ更新されます。 React の state を “信頼できる唯一の情報源 (single source of truth)” とすることで、上述の 2 つの状態を結合させることができます。そうすることで、フォームをレンダーしている React コンポーネントが、後続するユーザ入力でフォームで起きることも制御できるようになります。このような方法で React によって値が制御される入力フォーム要素は「制御されたコンポーネント」と呼ばれます。 例えば、前述のフォームの例において、フォーム送信時に名前をログに残すようにしたい場合、フォームを制御されたコンポーネントとして書くことができます： フォーム要素の value 属性が設定されているので、表示される値は常に this.state.value となり、React の state が信頼できる情報源となります。handleChange はキーストロークごとに実行されて React の state を更新するので、表示される値はユーザがタイプするたびに更新されます。 制御されたコンポーネントを使うと、ユーザ入力の値は常に React の state によって制御されるようになります。これによりタイプするコード量は少し増えますが、その値を他の UI … Read more

Reactでリストを作成する前に、JavaScript でリストを変換する方法についておさらいしましょう。 以下のコードでは、map() 関数を用い、numbers という配列を受け取って中身の値を 2 倍にしています。map() 関数が返す新しい配列を変数 doubled に格納し、ログに出力します： このコードはコンソールに [2, 4, 6, 8, 10] と出力します。 React で配列を要素のリストに変換する方法は上記に似ています。 複数のコンポーネントをレンダーする 要素の集合を作成し中括弧 {} で囲むことで JSX に含めることができます。 以下では、JavaScript の map() 関数を利用して、numbers という配列に対して反復処理を行っています。それぞれの整数に対して <li> 要素を返しています。最後に、結果として得られる要素の配列を listItems に格納しています： そして、listItems という配列全体を <ul> 要素の内側に含めます： このコードは、1 から 5 までの数字の箇条書きのリストを表示します。 基本的なリストコンポーネント 通常、リストは何らかのコンポーネントの内部でレンダーすることをが実用的です。 前の例をリファクタリングして、numbers という配列を受け取って要素のリストを出力するコンポーネントを作ることができます。 このコードを実行すると、「リスト項目には key を与えるべきだ」という警告が表示されます。“key” とは特別な文字列の属性であり、要素のリストを作成する際に含めておく必要があるものです。なぜ key が重要なのかは後に説明します。 numbers.map() 内のリスト項目に key を割り当てて、key が見つからないという問題を修正しましょう。 Key Key は、どの要素が変更、追加もしくは削除されたのかを React が識別するのに必要になります。配列内の項目に安定した識別性を与えるため、それぞれの項目に key を与えるべきです。 Keyはリレーショナルデータベースでいうプライマリーキーと同じイメージになります。いわば、ユニークなIDのことです。これで同じデータ（例：”田中さん”、”田中さん”）が複数あってもどのデータを指しているのかを判断できるようになりますね。 データ間でその項目を一意に特定できるような文字列を key として選ぶのが最良の方法です。多くの場合、のデータ内にある ID を key として使うことになるでしょう： レンダーされる要素に安定した ID がない場合、最終手段として項目のインデックス（順番）を使うことができます： 要素の並び順が変更される可能性がある場合、インデックスを key として使用することはお勧めしません。パフォーマンスに悪い影響を与え、コンポーネントの状態に問題を起こす可能性があるからです。もし明示的に key … Read more

React ではロジックをカプセル化した独立したコンポーネントを作ることができます。そして、あなたのアプリケーションの状態に応じて、その一部だけを更新、表示することが可能です。 React における条件付きレンダーは JavaScript における条件分岐と同じように動作します。if もしくは条件演算子のような JavaScript 演算子を使用して現在の状態を表す要素を作成すれば、React はそれに一致するように UI を更新します。 以下の 2 つのコンポーネントを見てみましょう。 ユーザがログインしているかどうかによって、これらのコンポーネントの一方だけを表示する Greeting コンポーネントを作成しましょう： この例では isLoggedIn プロパティの値によって異なる挨拶メッセージを表示します。 要素変数 要素を保持しておくために変数を使うことができます。これは、出力の他の部分を変えずにコンポーネントの一部を条件付きでレンダーしたい時に役立ちます。 ログアウトとログインボタンを表す以下の 2 つの新しいコンポーネントを考えましょう： 以下の例では、LoginControl というステート付きコンポーネントを作成します。 LoginControl は現在の state によって <LoginButton /> もしくは <LogoutButton /> の一方をレンダーします。加えて、前の例の <Greeting /> もレンダーします： Try it on CodePen 変数を宣言して if 文を使用することはコンポーネントを条件的にレンダーするなかなか良い方法ではありますが、より短い構文を使いたくなる時もあります。以下で述べるように、JSX でインラインで条件を記述する方法がいくつか存在します。 論理 && 演算子によるインライン If 中括弧で囲むことで、JSX に式を埋め込むことができます。これには JavaScript の論理 && 演算子も含まれます。これは条件に応じて要素を含めたいというときに便利です。 Try it on CodePen これが動作するのは、JavaScript では true && expression は必ず expression と評価され、false && expression は必ず false と評価されるからです。 従って、条件部分が true であれば、&& の後に書かれた要素が出力に現れます。もし false であれば、React はそれを無視して飛ばします。 falsy … Read more

React でのイベント処理は DOM 要素のイベントの処理と似ています。まずは、いくつかの文法的な違いがあるので見ておきましょう。 例として、以下の HTMLを見てください。 は、React では少し異なります： 別の違いとして、React では false を返してもデフォルトの動作を抑止することができません。明示的に preventDefault を呼び出す必要があります。例えば、プレーンな HTML では、「フォームをサブミットする」という form 要素のデフォルト動作を抑止するために次のように書くことができます。 React では、代わりに次のようになります： ここで、e は合成 (synthetic) イベントです。React はこれらの合成イベントを W3C の仕様に則って定義しているので、ブラウザ間の互換性を心配する必要はありません。React のイベントはネイティブのイベントと全く同様に動作するわけではありません。 React を使う場合、一般的には DOM 要素の生成後に addEventListener を呼び出してリスナを追加する必要はありません。代わりに、要素が最初にレンダーされる際にリスナを指定するようにしてください。 コンポーネントを ES6 のクラスを使用して定義した場合、一般的なパターンではイベントハンドラはクラスのメソッドになります。例えば、以下の Toggle コンポーネントはユーザが “ON” 状態 “OFF” 状態を切り替えられるようなボタンをレンダーします。 JSX のコールバックにおける this の意味に注意しなければなりません。JavaScript では、クラスのメソッドはデフォルトではバインドされません。this.handleClick へのバインドを忘れて onClick に渡した場合、実際に関数が呼ばれた時に this は undefined となってしまいます。 これは React に限った動作ではなく、JavaScript における関数の仕組みの一部です。一般的に、onClick={this.handleClick} のように () を末尾に付けずに何らかのメソッドを参照する場合、そのメソッドはバインドしておく必要があります。 bind の呼び出しが苦痛である場合、それを回避する方法が 2 つあります。パブリッククラスフィールド構文を使えば、コールバックを正しくバインドすることができます： この構文は、Create React App ではデフォルトで有効です。 クラスフィールド構文を使用しない場合、コールバック内でアロー関数を使用することもできます： この構文での問題は、LoggingButton がレンダーされるたびに異なるコールバック関数が毎回作成されるということです。大抵のケースではこれは問題ありません。しかし、このコールバックが props の一部として下層のコンポーネントに渡される場合、それら下層コンポーネントが余分に再描画されることになります。 一般的にはコンストラクタでバインドするかクラスフィールド構文を使用して、この種のパフォーマンスの問題を避けるようおすすめします。 イベントハンドラに引数を渡す ループ内では、イベントハンドラに追加のパラメータを渡したくなることがよくあります。例えば、id という行の ID がある場合、以下のどちらでも動作します： 上記の … Read more