feat: Thinking in React - Step 1

Author: Nkzn

content/docs/thinking-in-react.md

@@ -1,6 +1,6 @@
 ---
 id: thinking-in-react
-title: Reactの流儀
+title: Reactらしい考え方
 permalink: docs/thinking-in-react.html
 redirect_from:
   - 'blog/2013/11/05/thinking-in-react.html'
@@ -10,15 +10,15 @@ prev: composition-vs-inheritance.html
 
 巨大で軽快なWebアプリを開発する場合に、React は最高の手段であると、私たちは考えています。Facebook や Instagram といった私たちのサービスにおいても、とてもよくスケールしています。
 
-React には素晴らしい特徴がいくつもありますが、そのうちのひとつとして、アプリを組み立てる際には、そのアプリのことを考えていられる、というものがあります。本ドキュメントでは、検索可能な商品データ表を、Reactで作っていく過程を通してお見せします。
+React のすばらしい特長がいくつもありますが、あなたがどんなアプリを作ろうかと考えたことが、そのままアプリの作り方になる、というのはそのひとつです。本ドキュメントでは、検索可能な商品データ表を React で作っていく様子をお見せしましょう。
 
-## Start With A Mock
+## モックから始めよう
 
-Imagine that we already have a JSON API and a mock from our designer. The mock looks like this:
+すでに、JSON API が実装済みで、デザイナーからもデザインモックがもらえているとしましょう。モックは次のような見た目だったとします。
 
-![Mockup](../images/blog/thinking-in-react-mock.png)
+![デザインモック](../images/blog/thinking-in-react-mock.png)
 
-Our JSON API returns some data that looks like this:
+また、JSON API は次のようなデータを返してくるとしましょう。
 
 ```
 [
@@ -31,27 +31,28 @@ Our JSON API returns some data that looks like this:
 ];
 ```
 
-## Step 1: Break The UI Into A Component Hierarchy
+## Step 1: UIをコンポーネントの階層構造に落とし込む
 
-The first thing you'll want to do is to draw boxes around every component (and subcomponent) in the mock and give them all names. If you're working with a designer, they may have already done this, so go talk to them! Their Photoshop layer names may end up being the names of your React components!
+まず最初に行うのは、モックを形作っている各コンポーネント（構成要素）を四角で囲んで、それぞれに名前をつけていくことです。もしあなたがデザイナーと一緒に仕事をしている場合は、彼らがすでにこれに相当する作業を終えている可能性がありますので、話をしに行きましょう。彼らが Photoshop でレイヤ名にしていた名前が、最終的にはあなたの React コンポーネントの名前になりうるのです！
 
-But how do you know what should be its own component? Just use the same techniques for deciding if you should create a new function or object. One such technique is the [single responsibility principle](https://en.wikipedia.org/wiki/Single_responsibility_principle), that is, a component should ideally only do one thing. If it ends up growing, it should be decomposed into smaller subcomponents.
+しかし、どうやってコンポーネントとして括るべき範囲を見つけられるのでしょうか。ちょうど、関数やオブジェクトをどのような責任範囲で作るのかを決めるときと、同じ手法が使えます。このような手法のひとつに、[単一責任の原則](https://en.wikipedia.org/wiki/Single_responsibility_principle)があり、これに沿って考えると、ひとつのコンポーネントはひとつのことだけができるべきである、という指針が得られます。将来、コンポーネントが肥大化してしまった場合には、小さなコンポーネントに分割するべきである、という話でもあります。
 
-Since you're often displaying a JSON data model to a user, you'll find that if your model was built correctly, your UI (and therefore your component structure) will map nicely. That's because UI and data models tend to adhere to the same *information architecture*, which means the work of separating your UI into components is often trivial. Just break it up into components that represent exactly one piece of your data model.
+皆さんがこれまで JSON で作ったデータモデルをユーザーに向けて表示してきた経験から、モデルを正しく構築できていれば、UI（つまりコンポーネントの構造）へのデータマッピングも上手くいくであろうことは想像に難くないでしょう。これは、UIとデータモデルが同じ **情報の構造** を持つ傾向があるためです。このおかげで、UIをコンポーネントに切り分ける作業は自明なものになりがちです。データモデルの1要素を表現するコンポーネントに、モックを分割して落とし込んでみましょう。
 
-![Component diagram](../images/blog/thinking-in-react-components.png)
+![コンポーネント図](../images/blog/thinking-in-react-components.png)
 
-You'll see here that we have five components in our simple app. We've italicized the data each component represents.
+5種類のコンポーネントがこのシンプルなアプリの中にあることが見て取れます。それぞれの解説の中で、データを表すものについては斜体にしました。
+<!-- nkzn注: 日本語フォントは斜体を表現できないことが多いので、別の表現でマークアップしたほうがいいかもしれない -->
 
-  1. **`FilterableProductTable` (orange):** contains the entirety of the example
-  2. **`SearchBar` (blue):** receives all *user input*
-  3. **`ProductTable` (green):** displays and filters the *data collection* based on *user input*
-  4. **`ProductCategoryRow` (turquoise):** displays a heading for each *category*
-  5. **`ProductRow` (red):** displays a row for each *product*
+  1. **`FilterableProductTable`（オレンジ色）：** このサンプル全体を含む
+  2. **`SearchBar`（青色）：** すべての *ユーザー入力* を受け付ける
+  3. **`ProductTable`（緑色）：** *ユーザー入力* に基づく *データの集合* を表示・フィルターする
+  4. **`ProductCategoryRow`（水色）：** *カテゴリ* を見出しとして表示する
+  5. **`ProductRow`（赤色）：** 各 *商品* を1行で表示する
 
-If you look at `ProductTable`, you'll see that the table header (containing the "Name" and "Price" labels) isn't its own component. This is a matter of preference, and there's an argument to be made either way. For this example, we left it as part of `ProductTable` because it is part of rendering the *data collection* which is `ProductTable`'s responsibility. However, if this header grows to be complex (i.e. if we were to add affordances for sorting), it would certainly make sense to make this its own `ProductTableHeader` component.
+`ProductTable` を見てみると、表のヘッダー（「Name」や「Price」のラベルを含む）が自身のコンポーネントを持っていないことがわかります。これは好みの問題で、コンポーネントにするかしないかは両論あります。今回の例でいえば、ヘッダーを `ProductTable` の一部にしたのは、 *データの集合* を描画するという `ProductTable` の責務の一環として適切だったからです。しかしながら、将来ヘッダーが肥大化して複雑になった場合（ソート機能の追加など）は、 `ProductTableHeader` のようなコンポーネントにするのが適切になるでしょう。
 
-Now that we've identified the components in our mock, let's arrange them into a hierarchy. This is easy. Components that appear within another component in the mock should appear as a child in the hierarchy:
+さて、モック内にコンポーネントを定義できましたので、階層構造に並べてみましょう。簡単なことです。モックで他のコンポーネントの中にあるコンポーネントを、階層構造でも子要素として配置すればいいのです。次のようになります。
 
   * `FilterableProductTable`
     * `SearchBar`