シリーズ

基本講座の最後として、検索可能な商品データ表を 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