From 0062337b136b6e05991964a8b6d8d6f6b6336722 Mon Sep 17 00:00:00 2001 From: Yukiya Nakagawa Date: Sat, 2 Feb 2019 00:58:13 +0900 Subject: [PATCH 01/40] docs(thinking-in-react): write lead sentence --- content/docs/thinking-in-react.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 53caa2b20..9bc9854d2 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -1,6 +1,6 @@ --- id: thinking-in-react -title: Thinking in React +title: Reactの流儀 permalink: docs/thinking-in-react.html redirect_from: - 'blog/2013/11/05/thinking-in-react.html' @@ -8,9 +8,9 @@ redirect_from: prev: composition-vs-inheritance.html --- -React is, in our opinion, the premier way to build big, fast Web apps with JavaScript. It has scaled very well for us at Facebook and Instagram. +巨大で軽快なWebアプリを開発する場合に、React は最高の手段であると、私たちは考えています。Facebook や Instagram といった私たちのサービスにおいても、とてもよくスケールしています。 -One of the many great parts of React is how it makes you think about apps as you build them. In this document, we'll walk you through the thought process of building a searchable product data table using React. +React には素晴らしい特徴がいくつもありますが、そのうちのひとつとして、アプリを組み立てる際には、そのアプリのことを考えていられる、というものがあります。本ドキュメントでは、検索可能な商品データ表を、Reactで作っていく過程を通してお見せします。 ## Start With A Mock From 89d45ee2ec38b9db0d1090f8d7925f0e090c76e3 Mon Sep 17 00:00:00 2001 From: Yukiya Nakagawa Date: Sun, 3 Feb 2019 02:04:48 +0900 Subject: [PATCH 02/40] docs(thinking-in-react): Thinking in React - Step 1 --- content/docs/thinking-in-react.md | 39 ++++++++++++++++--------------- 1 file changed, 20 insertions(+), 19 deletions(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 9bc9854d2..f3cb9dab5 100644 --- a/content/docs/thinking-in-react.md +++ b/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種類のコンポーネントがこのシンプルなアプリの中にあることが見て取れます。それぞれの解説の中で、データを表すものについては斜体にしました。 + - 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` From 25db10b6f9d90913cf583149482a14cc4cba92f1 Mon Sep 17 00:00:00 2001 From: Yukiya Nakagawa Date: Sun, 3 Feb 2019 11:35:32 +0900 Subject: [PATCH 03/40] docs(thinking-in-react): add spaces --- content/docs/thinking-in-react.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index f3cb9dab5..e1f359301 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -31,17 +31,17 @@ React のすばらしい特長がいくつもありますが、あなたがど ]; ``` -## Step 1: UIをコンポーネントの階層構造に落とし込む +## Step 1: UI をコンポーネントの階層構造に落とし込む まず最初に行うのは、モックを形作っている各コンポーネント（構成要素）を四角で囲んで、それぞれに名前をつけていくことです。もしあなたがデザイナーと一緒に仕事をしている場合は、彼らがすでにこれに相当する作業を終えている可能性がありますので、話をしに行きましょう。彼らが Photoshop でレイヤ名にしていた名前が、最終的にはあなたの React コンポーネントの名前になりうるのです！ しかし、どうやってコンポーネントとして括るべき範囲を見つけられるのでしょうか。ちょうど、関数やオブジェクトをどのような責任範囲で作るのかを決めるときと、同じ手法が使えます。このような手法のひとつに、[単一責任の原則](https://en.wikipedia.org/wiki/Single_responsibility_principle)があり、これに沿って考えると、ひとつのコンポーネントはひとつのことだけができるべきである、という指針が得られます。将来、コンポーネントが肥大化してしまった場合には、小さなコンポーネントに分割するべきである、という話でもあります。 -皆さんがこれまで JSON で作ったデータモデルをユーザーに向けて表示してきた経験から、モデルを正しく構築できていれば、UI（つまりコンポーネントの構造）へのデータマッピングも上手くいくであろうことは想像に難くないでしょう。これは、UIとデータモデルが同じ **情報の構造** を持つ傾向があるためです。このおかげで、UIをコンポーネントに切り分ける作業は自明なものになりがちです。データモデルの1要素を表現するコンポーネントに、モックを分割して落とし込んでみましょう。 +皆さんがこれまで JSON で作ったデータモデルをユーザーに向けて表示してきた経験から、モデルを正しく構築できていれば、UI（つまりコンポーネントの構造）へのデータマッピングも上手くいくであろうことは想像に難くないでしょう。これは、UI とデータモデルが同じ **情報の構造** を持つ傾向があるためです。このおかげで、UI をコンポーネントに切り分ける作業は自明なものになりがちです。データモデルの 1 要素を表現するコンポーネントに、モックを分割して落とし込んでみましょう。 ![コンポーネント図](../images/blog/thinking-in-react-components.png) -5種類のコンポーネントがこのシンプルなアプリの中にあることが見て取れます。それぞれの解説の中で、データを表すものについては斜体にしました。 +5 種類のコンポーネントがこのシンプルなアプリの中にあることが見て取れます。それぞれの解説の中で、データを表すものについては斜体にしました。 1. **`FilterableProductTable`（オレンジ色）：** このサンプル全体を含む From 5e138c8bd73c038c3cf3d2f9b6f9e9edde86f58b Mon Sep 17 00:00:00 2001 From: Yukiya Nakagawa Date: Sun, 3 Feb 2019 15:41:27 +0900 Subject: [PATCH 04/40] docs(thinking-in-react): Add "Single Responsibility Principle" expression. --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index e1f359301..b0ba3d8b7 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -35,7 +35,7 @@ React のすばらしい特長がいくつもありますが、あなたがど まず最初に行うのは、モックを形作っている各コンポーネント（構成要素）を四角で囲んで、それぞれに名前をつけていくことです。もしあなたがデザイナーと一緒に仕事をしている場合は、彼らがすでにこれに相当する作業を終えている可能性がありますので、話をしに行きましょう。彼らが Photoshop でレイヤ名にしていた名前が、最終的にはあなたの React コンポーネントの名前になりうるのです！ -しかし、どうやってコンポーネントとして括るべき範囲を見つけられるのでしょうか。ちょうど、関数やオブジェクトをどのような責任範囲で作るのかを決めるときと、同じ手法が使えます。このような手法のひとつに、[単一責任の原則](https://en.wikipedia.org/wiki/Single_responsibility_principle)があり、これに沿って考えると、ひとつのコンポーネントはひとつのことだけができるべきである、という指針が得られます。将来、コンポーネントが肥大化してしまった場合には、小さなコンポーネントに分割するべきである、という話でもあります。 +しかし、どうやってコンポーネントとして括るべき範囲を見つけられるのでしょうか。ちょうど、関数やオブジェクトをどのような責任範囲で作るのかを決めるときと、同じ手法が使えます。このような手法のひとつに、[単一責任の原則（Single Responsibility Principle）](https://en.wikipedia.org/wiki/Single_responsibility_principle)があり、これに沿って考えると、ひとつのコンポーネントはひとつのことだけができるべきである、という指針が得られます。将来、コンポーネントが肥大化してしまった場合には、小さなコンポーネントに分割するべきである、という話でもあります。 皆さんがこれまで JSON で作ったデータモデルをユーザーに向けて表示してきた経験から、モデルを正しく構築できていれば、UI（つまりコンポーネントの構造）へのデータマッピングも上手くいくであろうことは想像に難くないでしょう。これは、UI とデータモデルが同じ **情報の構造** を持つ傾向があるためです。このおかげで、UI をコンポーネントに切り分ける作業は自明なものになりがちです。データモデルの 1 要素を表現するコンポーネントに、モックを分割して落とし込んでみましょう。 From 60026ec379bd6c76853ab0cbef793a48cf6c46f1 Mon Sep 17 00:00:00 2001 From: Yukiya Nakagawa Date: Sun, 3 Feb 2019 15:41:45 +0900 Subject: [PATCH 05/40] docs(thinking-in-react): Add spaces --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index b0ba3d8b7..e1e993afd 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -48,7 +48,7 @@ React のすばらしい特長がいくつもありますが、あなたがど 2. **`SearchBar`（青色）：** すべての *ユーザー入力* を受け付ける 3. **`ProductTable`（緑色）：** *ユーザー入力* に基づく *データの集合* を表示・フィルターする 4. **`ProductCategoryRow`（水色）：** *カテゴリ* を見出しとして表示する - 5. **`ProductRow`（赤色）：** 各 *商品* を1行で表示する + 5. **`ProductRow`（赤色）：** 各 *商品* を 1 行で表示する `ProductTable` を見てみると、表のヘッダー（「Name」や「Price」のラベルを含む）が自身のコンポーネントを持っていないことがわかります。これは好みの問題で、コンポーネントにするかしないかは両論あります。今回の例でいえば、ヘッダーを `ProductTable` の一部にしたのは、 *データの集合* を描画するという `ProductTable` の責務の一環として適切だったからです。しかしながら、将来ヘッダーが肥大化して複雑になった場合（例えばソート機能を追加した場合など）は、 `ProductTableHeader` のようなコンポーネントにするのが適切になるでしょう。 From 86f80721f3d7904a6febd80a67aa667dae22c9c5 Mon Sep 17 00:00:00 2001 From: Yukiya Nakagawa Date: Sun, 3 Feb 2019 15:43:52 +0900 Subject: [PATCH 06/40] docs(thinking-in-react): Thinking in React - Step 2 --- content/docs/thinking-in-react.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index e1e993afd..9a1005395 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -60,24 +60,24 @@ React のすばらしい特長がいくつもありますが、あなたがど * `ProductCategoryRow` * `ProductRow` -## Step 2: Build A Static Version in React +## Step 2：Reactで静的なバージョンを作成する

See the Pen Thinking In React: Step 2 on CodePen.

-Now that you have your component hierarchy, it's time to implement your app. The easiest way is to build a version that takes your data model and renders the UI but has no interactivity. It's best to decouple these processes because building a static version requires a lot of typing and no thinking, and adding interactivity requires a lot of thinking and not a lot of typing. We'll see why. +さて、コンポーネントの階層構造が決まったので、アプリの実装に取り掛かりましょう。最初は、データモデルを使用して UI の描画だけを行い、ユーザーからの操作はできないというバージョンを作っるのが、もっとも簡単でしょう。なぜ最初から操作できるバージョンを作らないのでしょうか。多くの場合、静的な（操作できない）バージョンを作る際には、タイピングする量が多い代わりに悩むことが少ない傾向があります。逆に、操作できるように改修するときには、悩ましいことが多い代わりにタイピングの量は少ない傾向があります。そういった理由から、先に操作できないバージョンを作ります。 -To build a static version of your app that renders your data model, you'll want to build components that reuse other components and pass data using *props*. *props* are a way of passing data from parent to child. If you're familiar with the concept of *state*, **don't use state at all** to build this static version. State is reserved only for interactivity, that is, data that changes over time. Since this is a static version of the app, you don't need it. +データモデルを描画するだけの機能を持った、静的なバージョンのアプリを作る際には、再利用可能なコンポーネントを組み合わせて、それらに *props* を通じてデータを渡す形で、自分のコンポーネントを組み上げていきたいですよね。*props* は親から子へとデータを渡すための手段です。もし、あなたが *state* に慣れ親しんでいる場合でも、今回の静的なバージョンを作る上では**一切 state を使わないでください。** state はユーザー操作や時間経過などで動的に変化するデータを扱うために確保されている機能です。今回のアプリは静的なバージョンなので、stateは必要ありません。 -You can build top-down or bottom-up. That is, you can either start with building the components higher up in the hierarchy (i.e. starting with `FilterableProductTable`) or with the ones lower in it (`ProductRow`). In simpler examples, it's usually easier to go top-down, and on larger projects, it's easier to go bottom-up and write tests as you build. +コンポーネントはトップダウンで作っても、ボトムアップで作っても問題ありません。 つまり、高い階層にあるコンポーネント（例えば `FilterableProductTable`）から作り始めても、低い階層にあるコンポーネント（`ProductRow` など）から作り始めても、どちらでもいいのです。身近な話題に置き換えて考えてみると、システム開発プロジェクトの進行は、多くの場合トップダウンで進めたほうがやりやすいですが、巨大なプロジェクトなら、ボトムアップで開発を進めるたびに自動テストを書いていったほうがやりやすい、といった話題が近いかもしれません。 -At the end of this step, you'll have a library of reusable components that render your data model. The components will only have `render()` methods since this is a static version of your app. The component at the top of the hierarchy (`FilterableProductTable`) will take your data model as a prop. If you make a change to your underlying data model and call `ReactDOM.render()` again, the UI will be updated. It's easy to see how your UI is updated and where to make changes since there's nothing complicated going on. React's **one-way data flow** (also called *one-way binding*) keeps everything modular and fast. +最後に、再利用可能な、データモデルを描画するためのコンポーネントで作るライブラリについて考えてみましょう。今回のアプリは静的なバージョンなので、コンポーネントは `render()` メソッドだけを持つことになります。階層構造の中で最上位のコンポーネント（`FilterableProductTable`）が、データモデルを props として受け取ることになるでしょう。一度アプリを表示した後、あなたが元となるデータモデルを更新して再度 `ReactDOM.render()` を呼び出すと、UI が更新されることになります。このやり方なら、複雑なことをしていないので、UI がどのように更新されて、どこを変更すればよいか、容易に理解できることでしょう。React の**単方向データフロー**（あるいは*単方向バインディング*）は、すべてをモジュール化し、高速化します。 -Simply refer to the [React docs](/docs/) if you need help executing this step. +このステップを実施する上で助けが必要な場合は、[React ドキュメント](/docs/)を参照してください。 -### A Brief Interlude: Props vs State +### 幕間：Props vs State -There are two types of "model" data in React: props and state. It's important to understand the distinction between the two; skim [the official React docs](/docs/interactivity-and-dynamic-uis.html) if you aren't sure what the difference is. +React には 2 種類の「モデル」データが存在します。 props と state です。このふたつの相違を理解するのは重要なことです。もしあなたがこれらの違いについての知識に自信がない場合は、[公式の React ドキュメント](/docs/interactivity-and-dynamic-uis.html)に目を通すとよいでしょう。 ## Step 3: Identify The Minimal (but complete) Representation Of UI State From e874a5a2d90a085201c7eb54cf4dc226e4787af4 Mon Sep 17 00:00:00 2001 From: Yukiya Nakagawa Date: Sun, 3 Feb 2019 20:10:30 +0900 Subject: [PATCH 07/40] =?UTF-8?q?docs(thinking-in-react):=20=E3=83=95?= =?UTF-8?q?=E3=82=A3=E3=83=AB=E3=82=BF=E3=83=BC=20=3D>=20=E3=83=95?= =?UTF-8?q?=E3=82=A3=E3=83=AB=E3=82=BF?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 9a1005395..eda60e3ec 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -46,7 +46,7 @@ React のすばらしい特長がいくつもありますが、あなたがど 1. **`FilterableProductTable`（オレンジ色）：** このサンプル全体を含む 2. **`SearchBar`（青色）：** すべての *ユーザー入力* を受け付ける - 3. **`ProductTable`（緑色）：** *ユーザー入力* に基づく *データの集合* を表示・フィルターする + 3. **`ProductTable`（緑色）：** *ユーザー入力* に基づく *データの集合* を表示・フィルタする 4. **`ProductCategoryRow`（水色）：** *カテゴリ* を見出しとして表示する 5. **`ProductRow`（赤色）：** 各 *商品* を 1 行で表示する From e21131d59970512a72b15de92aec953f4d61bca3 Mon Sep 17 00:00:00 2001 From: Yukiya Nakagawa Date: Sun, 3 Feb 2019 20:11:55 +0900 Subject: [PATCH 08/40] docs(thinking-in-react): Thinking in React - Step 3 --- content/docs/thinking-in-react.md | 32 +++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index eda60e3ec..4bb656157 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -79,31 +79,31 @@ React のすばらしい特長がいくつもありますが、あなたがど React には 2 種類の「モデル」データが存在します。 props と state です。このふたつの相違を理解するのは重要なことです。もしあなたがこれらの違いについての知識に自信がない場合は、[公式の React ドキュメント](/docs/interactivity-and-dynamic-uis.html)に目を通すとよいでしょう。 -## Step 3: Identify The Minimal (but complete) Representation Of UI State +## Step 3：UI の状態を最小の（しかし完全な）形で表現する -To make your UI interactive, you need to be able to trigger changes to your underlying data model. React makes this easy with **state**. +UI をインタラクティブなものにするにあたり、UIを構築する元となっているデータモデルを更新できるようにしておきたいですね。React なら **state** を使うことで容易に実現できます。 -To build your app correctly, you first need to think of the minimal set of mutable state that your app needs. The key here is [DRY: *Don't Repeat Yourself*](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). Figure out the absolute minimal representation of the state your application needs and compute everything else you need on-demand. For example, if you're building a TODO list, just keep an array of the TODO items around; don't keep a separate state variable for the count. Instead, when you want to render the TODO count, simply take the length of the TODO items array. +適切に開発を進めていくにあたり、そのアプリに求められている更新可能な状態の最小構成を、最初に考えておいたほうがよいでしょう。ここで重要なのは、[DRY（*Don't Repeat Yourself*）](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)の原則です。アプリケーションが必要としている最小限の状態を把握しておき、他に必要なものが出てきたら、そのとき計算すればよいのです。例を挙げてみましょう。もしあなたがTODOリストを作ることになったら、TODOの各項目を配列で保持しますよね。個数のカウント用に、別の状態変数を持ったりはしません。その代わりに、TODOの項目数を表示したいのであれば、単純に配列の length を使えばよいのです。 -Think of all of the pieces of data in our example application. We have: +今回のサンプルアプリを形作るデータについて考えてみましょう。次のようなデータがあります。 - * The original list of products - * The search text the user has entered - * The value of the checkbox - * The filtered list of products + * 元となる商品のリスト + * ユーザーが入力した検索文字列 + * チェックボックスの値 + * フィルタ済みの商品のリスト -Let's go through each one and figure out which one is state. Simply ask three questions about each piece of data: +それぞれについて見ていき、どれが state になりうるのかを考えてみます。各データについて、 3 つの質問をするだけです。 - 1. Is it passed in from a parent via props? If so, it probably isn't state. - 2. Does it remain unchanged over time? If so, it probably isn't state. - 3. Can you compute it based on any other state or props in your component? If so, it isn't state. + 1. 親から props を通じて与えられたデータでしょうか？　もしそうなら、それは state ではありません + 2. 時間経過で変化しないままでいるデータでしょうか？　もしそうなら、それは state ではありません + 3. コンポーネント内にある他の props や state を使って算出可能なデータでしょうか？　もしそうなら、それは state ではありません -The original list of products is passed in as props, so that's not state. The search text and the checkbox seem to be state since they change over time and can't be computed from anything. And finally, the filtered list of products isn't state because it can be computed by combining the original list of products with the search text and value of the checkbox. +元となる商品のリストは props から渡されるので、これは state ではありません。検索文字列とチェックボックスは時間の経過の中で変化し、また、算出することもできないため、state だと思われます。最後に、フィルタ済みの商品のリストは state ではありません。何故ならば、元となる商品のリストと検索文字列とチェックボックスの値を組み合わせることで、フィルタ済みの商品のリストを算出することが可能だからです。 -So finally, our state is: +というわけで、state と呼べるのは次の 2 つです。 - * The search text the user has entered - * The value of the checkbox + * ユーザーが入力した検索文字列 + * チェックボックスの値 ## Step 4: Identify Where Your State Should Live From f287a6fc3b80858f59a01ad60aff3123b617b822 Mon Sep 17 00:00:00 2001 From: Yukiya Nakagawa Date: Mon, 4 Feb 2019 00:00:06 +0900 Subject: [PATCH 09/40] =?UTF-8?q?docs(thinking-in-react):=20Step=203?= =?UTF-8?q?=E3=81=AE=E9=82=A6=E9=A1=8C=E3=82=92=E5=A4=89=E6=9B=B4=E3=81=97?= =?UTF-8?q?=E3=81=BE=E3=81=97=E3=81=9F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 4bb656157..34c1c2f13 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -79,7 +79,7 @@ React のすばらしい特長がいくつもありますが、あなたがど React には 2 種類の「モデル」データが存在します。 props と state です。このふたつの相違を理解するのは重要なことです。もしあなたがこれらの違いについての知識に自信がない場合は、[公式の React ドキュメント](/docs/interactivity-and-dynamic-uis.html)に目を通すとよいでしょう。 -## Step 3：UI の状態を最小の（しかし完全な）形で表現する +## Step 3：UI が持つ state の最小構成を明確にする UI をインタラクティブなものにするにあたり、UIを構築する元となっているデータモデルを更新できるようにしておきたいですね。React なら **state** を使うことで容易に実現できます。 From 930c87d7acb375ab4fd03bc8c005735078238a22 Mon Sep 17 00:00:00 2001 From: Yukiya Nakagawa Date: Mon, 4 Feb 2019 00:00:42 +0900 Subject: [PATCH 10/40] docs(thinking-in-react): Thinking in React - Step 4 --- content/docs/thinking-in-react.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 34c1c2f13..b986af76f 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -105,30 +105,30 @@ UI をインタラクティブなものにするにあたり、UIを構築する * ユーザーが入力した検索文字列 * チェックボックスの値 -## Step 4: Identify Where Your State Should Live +## Step 4：state をどこに配置するべきなのかを明確にする

See the Pen Thinking In React: Step 4 on CodePen.

-OK, so we've identified what the minimal set of app state is. Next, we need to identify which component mutates, or *owns*, this state. +さて、state の最小構成が明確になりました。次は、どのコンポーネントを変化させるのか、そして*どのコンポーネントが state を持つのか*を明確にしましょう。 -Remember: React is all about one-way data flow down the component hierarchy. It may not be immediately clear which component should own what state. **This is often the most challenging part for newcomers to understand,** so follow these steps to figure it out: +復習：React は、コンポーネントの階層構造をデータが下っていく、単方向データフローで成り立っています。もしかすると、どのコンポーネントがどんな state を持つべきなのかが、すぐにはわからないかもしれません。**これは、初学者がReactへの理解を深める上で、最も難しい問題になりがちなところ** なので、ステップを踏みながら理解していきましょう。 -For each piece of state in your application: +アプリの各 state について、次の各項目を確認していきます。 - * Identify every component that renders something based on that state. - * Find a common owner component (a single component above all the components that need the state in the hierarchy). - * Either the common owner or another component higher up in the hierarchy should own the state. - * If you can't find a component where it makes sense to own the state, create a new component simply for holding the state and add it somewhere in the hierarchy above the common owner component. + * その state を使って表示を行う、すべてのコンポーネントを確認する + * 共通の親コンポーネントを見つける（その階層構造の中で、ある state を必要としているすべてのコンポーネントの真上にある単一のコンポーネントのことです） + * 共通の親コンポーネントか、その階層構造でさらに上位の別のコンポーネントが state を持っているべきである + * もし state を持つにふさわしいコンポーネントを見つけられなかった場合は、state を保持するためのコンポーネントを作り、そこに state を置いた上で、階層構造の中ですでに見つけていた共通の親コンポーネントの上に配置する -Let's run through this strategy for our application: +それでは、この戦術をサンプルアプリにも適用してみましょう。 - * `ProductTable` needs to filter the product list based on state and `SearchBar` needs to display the search text and checked state. - * The common owner component is `FilterableProductTable`. - * It conceptually makes sense for the filter text and checked value to live in `FilterableProductTable` + * `ProductTable` は商品リストをフィルタする必要があり、`SearchBar` は検索文字列とチェック状態を表示する必要がある + * 共通の親コンポーネントは `FilterableProductTable` である + * 概念的にも、検索文字列とチェック状態が `FilterableProductTable` に配置されることは妥当である -Cool, so we've decided that our state lives in `FilterableProductTable`. First, add an instance property `this.state = {filterText: '', inStockOnly: false}` to `FilterableProductTable`'s `constructor` to reflect the initial state of your application. Then, pass `filterText` and `inStockOnly` to `ProductTable` and `SearchBar` as a prop. Finally, use these props to filter the rows in `ProductTable` and set the values of the form fields in `SearchBar`. +いいですね。state を `FilterableProductTable` の中に配置することが決まりました。では早速、インスタンス変数として `this.state = {filterText: '', inStockOnly: false}` を `FilterableProductTable` の `constructor` に追加して、初期状態をアプリに反映しましょう。その次は、`filterText` と `inStockOnly` を `ProductTable` と `SearchBar` に props として渡します。最後に、これらの props を使って `ProductTable` のフィルタ処理を行い、`SearchBar` のフォームにも値を埋めます。 -You can start seeing how your application will behave: set `filterText` to `"ball"` and refresh your app. You'll see that the data table is updated correctly. +これで、このアプリがどんな振る舞いをするのか見られるようになってきました。`filterText` に `"ball"` と入力した状態でアプリを更新すると、データの表が正しく更新されたことが確認できるはずです。 ## Step 5: Add Inverse Data Flow From 6cc5bbc7b7a22b1dc8655492e63b23d6eb25ce44 Mon Sep 17 00:00:00 2001 From: Yukiya Nakagawa Date: Mon, 4 Feb 2019 00:53:28 +0900 Subject: [PATCH 11/40] docs(thinking-in-react): Thinking in React - Step 5 & 'And That's It' --- content/docs/thinking-in-react.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index b986af76f..5c9d83a22 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -130,20 +130,20 @@ UI をインタラクティブなものにするにあたり、UIを構築する これで、このアプリがどんな振る舞いをするのか見られるようになってきました。`filterText` に `"ball"` と入力した状態でアプリを更新すると、データの表が正しく更新されたことが確認できるはずです。 -## Step 5: Add Inverse Data Flow +## Step 5：逆方向のデータフローを追加する

See the Pen Thinking In React: Step 5 on CodePen.

-So far, we've built an app that renders correctly as a function of props and state flowing down the hierarchy. Now it's time to support data flowing the other way: the form components deep in the hierarchy need to update the state in `FilterableProductTable`. +ここまでで、props と state が階層構造を流れ落ちていく関数として、正しく描画を行うアプリを作ることができました。それでは、別の方向のデータフローもサポートしてみましょう。階層構造の奥深くにあるフォームのコンポーネントが、`FilterableProductTable` にある state を更新できるようにするのです。 -React makes this data flow explicit to make it easy to understand how your program works, but it does require a little more typing than traditional two-way data binding. +React はデータフローを明示的にしてプログラムの動作を理解しやすくするためのものですが、従来の双方向データバインディングよりも少し手を動かす必要があります。 -If you try to type or check the box in the current version of the example, you'll see that React ignores your input. This is intentional, as we've set the `value` prop of the `input` to always be equal to the `state` passed in from `FilterableProductTable`. +試しに、現在のバージョンのサンプルで文字を打ち込んだり、チェックボックスを切り替えてみると、React がその入力を無視することがわかります。これは意図的な挙動で、`input` の `value` props が、常に `FilterableProductTable` から渡された `state` と同じ値になるようにセットしてあるのです。 -Let's think about what we want to happen. We want to make sure that whenever the user changes the form, we update the state to reflect the user input. Since components should only update their own state, `FilterableProductTable` will pass callbacks to `SearchBar` that will fire whenever the state should be updated. We can use the `onChange` event on the inputs to be notified of it. The callbacks passed by `FilterableProductTable` will call `setState()`, and the app will be updated. +それでは、どんな挙動になってほしいのかを考えてみましょう。ユーザーがフォームを変更するたびに、ユーザー入力を反映するように state を更新したいですね。コンポーネントの state を更新できるのは自分自身だけであるべきなので、 `FilterableProductTable` は `SearchBar` にコールバックを渡して置いて、state を更新したいときにコールバックを実行してもらうようにします。入力のたびに呼び出される `onChange` イベントを利用するとよいでしょう。このコールバックを実行された `FilterableProductTable` は、`setState()` を呼び出し、その結果としてアプリが更新されます。 -Though this sounds complex, it's really just a few lines of code. And it's really explicit how your data is flowing throughout the app. +これは複雑に思えるかもしれませんが、ほんの数行のコードです。 そして、これらはデータがアプリの中をどのように流れているのかを、明確に示しているのです。 -## And That's It +## 終わりに -Hopefully, this gives you an idea of how to think about building components and applications with React. While it may be a little more typing than you're used to, remember that code is read far more than it's written, and it's extremely easy to read this modular, explicit code. As you start to build large libraries of components, you'll appreciate this explicitness and modularity, and with code reuse, your lines of code will start to shrink. :) +うまくいけば、これで React を使ってコンポーネントやアプリケーションを構築する方法について考えることができるようになります。それはもしかしたら、あなたのこれまでのやり方よりも、多くのコードを書くことになるかもしれません。しかしながら、コードは書くよりも読むことのほうが多いことや、モジュール化されていて明示的であるコードは非常に読みやすいということを思い出してください。大規模なコンポーネントのライブラリを構築し始めると、この明示性やモジュール化しやすさを高く評価することになり、コードを再利用することになり、あなたが書くコードの行数は減っていくのです。:) From 7a8e0633b5e27dd1d17ad5067b2bd30ab7fa660c Mon Sep 17 00:00:00 2001 From: Toru Kobayashi Date: Tue, 5 Feb 2019 11:36:40 +0900 Subject: [PATCH 12/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 5c9d83a22..3cc7b543f 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -65,7 +65,7 @@ React のすばらしい特長がいくつもありますが、あなたがど

See the Pen Thinking In React: Step 2 on CodePen.

-さて、コンポーネントの階層構造が決まったので、アプリの実装に取り掛かりましょう。最初は、データモデルを使用して UI の描画だけを行い、ユーザーからの操作はできないというバージョンを作っるのが、もっとも簡単でしょう。なぜ最初から操作できるバージョンを作らないのでしょうか。多くの場合、静的な（操作できない）バージョンを作る際には、タイピングする量が多い代わりに悩むことが少ない傾向があります。逆に、操作できるように改修するときには、悩ましいことが多い代わりにタイピングの量は少ない傾向があります。そういった理由から、先に操作できないバージョンを作ります。 +さて、コンポーネントの階層構造が決まったので、アプリの実装に取り掛かりましょう。最初は、データモデルを使用して UI の描画だけを行い、ユーザーからの操作はできないというバージョンを作るのが、もっとも簡単でしょう。なぜ最初から操作できるバージョンを作らないのでしょうか。多くの場合、静的な（操作できない）バージョンを作る際には、タイピングする量が多い代わりに悩むことが少ない傾向があります。逆に、操作できるように改修するときには、悩ましいことが多い代わりにタイピングの量は少ない傾向があります。そういった理由から、先に操作できないバージョンを作ります。 データモデルを描画するだけの機能を持った、静的なバージョンのアプリを作る際には、再利用可能なコンポーネントを組み合わせて、それらに *props* を通じてデータを渡す形で、自分のコンポーネントを組み上げていきたいですよね。*props* は親から子へとデータを渡すための手段です。もし、あなたが *state* に慣れ親しんでいる場合でも、今回の静的なバージョンを作る上では**一切 state を使わないでください。** state はユーザー操作や時間経過などで動的に変化するデータを扱うために確保されている機能です。今回のアプリは静的なバージョンなので、stateは必要ありません。 From ab2d566c529aa04f62a16d53432b8c17219839b2 Mon Sep 17 00:00:00 2001 From: Toru Kobayashi Date: Tue, 5 Feb 2019 11:36:53 +0900 Subject: [PATCH 13/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 3cc7b543f..c769b77e3 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -81,7 +81,7 @@ React には 2 種類の「モデル」データが存在します。 props と ## Step 3：UI が持つ state の最小構成を明確にする -UI をインタラクティブなものにするにあたり、UIを構築する元となっているデータモデルを更新できるようにしておきたいですね。React なら **state** を使うことで容易に実現できます。 +UI をインタラクティブなものにするにあたり、UI を構築する元となっているデータモデルを更新できるようにしておきたいですね。React なら **state** を使うことで容易に実現できます。 適切に開発を進めていくにあたり、そのアプリに求められている更新可能な状態の最小構成を、最初に考えておいたほうがよいでしょう。ここで重要なのは、[DRY（*Don't Repeat Yourself*）](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)の原則です。アプリケーションが必要としている最小限の状態を把握しておき、他に必要なものが出てきたら、そのとき計算すればよいのです。例を挙げてみましょう。もしあなたがTODOリストを作ることになったら、TODOの各項目を配列で保持しますよね。個数のカウント用に、別の状態変数を持ったりはしません。その代わりに、TODOの項目数を表示したいのであれば、単純に配列の length を使えばよいのです。 From fa807fdfb19d38e6ffff386510454db34e32991f Mon Sep 17 00:00:00 2001 From: Toru Kobayashi Date: Tue, 5 Feb 2019 11:37:19 +0900 Subject: [PATCH 14/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index c769b77e3..457dc5b5c 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -83,7 +83,7 @@ React には 2 種類の「モデル」データが存在します。 props と UI をインタラクティブなものにするにあたり、UI を構築する元となっているデータモデルを更新できるようにしておきたいですね。React なら **state** を使うことで容易に実現できます。 -適切に開発を進めていくにあたり、そのアプリに求められている更新可能な状態の最小構成を、最初に考えておいたほうがよいでしょう。ここで重要なのは、[DRY（*Don't Repeat Yourself*）](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)の原則です。アプリケーションが必要としている最小限の状態を把握しておき、他に必要なものが出てきたら、そのとき計算すればよいのです。例を挙げてみましょう。もしあなたがTODOリストを作ることになったら、TODOの各項目を配列で保持しますよね。個数のカウント用に、別の状態変数を持ったりはしません。その代わりに、TODOの項目数を表示したいのであれば、単純に配列の length を使えばよいのです。 +適切に開発を進めていくにあたり、そのアプリに求められている更新可能な状態の最小構成を、最初に考えておいたほうがよいでしょう。ここで重要なのは、[DRY（*Don't Repeat Yourself*）](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)の原則です。アプリケーションが必要としている最小限の状態を把握しておき、他に必要なものが出てきたら、そのとき計算すればよいのです。例を挙げてみましょう。もしあなたが TODO リストを作ることになったら、TODO の各項目を配列で保持しますよね。個数のカウント用に、別の状態変数を持ったりはしません。その代わりに、TODO の項目数を表示したいのであれば、単純に配列の length を使えばよいのです。 今回のサンプルアプリを形作るデータについて考えてみましょう。次のようなデータがあります。 From 97fd7cff5ca0f5e591acffe60bd5d526aa78ad3c Mon Sep 17 00:00:00 2001 From: Toru Kobayashi Date: Tue, 5 Feb 2019 11:37:41 +0900 Subject: [PATCH 15/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 457dc5b5c..4009d0d36 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -140,7 +140,7 @@ React はデータフローを明示的にしてプログラムの動作を理 試しに、現在のバージョンのサンプルで文字を打ち込んだり、チェックボックスを切り替えてみると、React がその入力を無視することがわかります。これは意図的な挙動で、`input` の `value` props が、常に `FilterableProductTable` から渡された `state` と同じ値になるようにセットしてあるのです。 -それでは、どんな挙動になってほしいのかを考えてみましょう。ユーザーがフォームを変更するたびに、ユーザー入力を反映するように state を更新したいですね。コンポーネントの state を更新できるのは自分自身だけであるべきなので、 `FilterableProductTable` は `SearchBar` にコールバックを渡して置いて、state を更新したいときにコールバックを実行してもらうようにします。入力のたびに呼び出される `onChange` イベントを利用するとよいでしょう。このコールバックを実行された `FilterableProductTable` は、`setState()` を呼び出し、その結果としてアプリが更新されます。 +それでは、どんな挙動になってほしいのかを考えてみましょう。ユーザーがフォームを変更するたびに、ユーザー入力を反映するように state を更新したいですね。コンポーネントの state を更新できるのは自分自身だけであるべきなので、 `FilterableProductTable` は `SearchBar` にコールバックを渡して、state を更新したいときにコールバックを実行してもらうようにします。入力のたびに呼び出される `onChange` イベントを利用するとよいでしょう。このコールバックを実行された `FilterableProductTable` は、`setState()` を呼び出し、その結果としてアプリが更新されます。 これは複雑に思えるかもしれませんが、ほんの数行のコードです。 そして、これらはデータがアプリの中をどのように流れているのかを、明確に示しているのです。 From ac1efb69e396ff3f08eba797bef56210970b41af Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:38:59 +0900 Subject: [PATCH 16/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 4009d0d36..d107e0926 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -35,7 +35,7 @@ React のすばらしい特長がいくつもありますが、あなたがど まず最初に行うのは、モックを形作っている各コンポーネント（構成要素）を四角で囲んで、それぞれに名前をつけていくことです。もしあなたがデザイナーと一緒に仕事をしている場合は、彼らがすでにこれに相当する作業を終えている可能性がありますので、話をしに行きましょう。彼らが Photoshop でレイヤ名にしていた名前が、最終的にはあなたの React コンポーネントの名前になりうるのです！ -しかし、どうやってコンポーネントとして括るべき範囲を見つけられるのでしょうか。ちょうど、関数やオブジェクトをどのような責任範囲で作るのかを決めるときと、同じ手法が使えます。このような手法のひとつに、[単一責任の原則（Single Responsibility Principle）](https://en.wikipedia.org/wiki/Single_responsibility_principle)があり、これに沿って考えると、ひとつのコンポーネントはひとつのことだけができるべきである、という指針が得られます。将来、コンポーネントが肥大化してしまった場合には、小さなコンポーネントに分割するべきである、という話でもあります。 +しかし、どうやって単一のコンポーネントに括るべき範囲を見つけられるのでしょうか。ちょうど、新しい関数やオブジェクトをいつ作るのかを決めるときと、同じ手法が使えます。このような手法のひとつに、[単一責任の原則 (single responsibility principle)](https://en.wikipedia.org/wiki/Single_responsibility_principle) があり、これはすなわち、ひとつのコンポーネントは理想的にはひとつのことだけをするべきだということです。将来、コンポーネントが肥大化してしまった場合には、小さなコンポーネントに分割するべきです。 皆さんがこれまで JSON で作ったデータモデルをユーザーに向けて表示してきた経験から、モデルを正しく構築できていれば、UI（つまりコンポーネントの構造）へのデータマッピングも上手くいくであろうことは想像に難くないでしょう。これは、UI とデータモデルが同じ **情報の構造** を持つ傾向があるためです。このおかげで、UI をコンポーネントに切り分ける作業は自明なものになりがちです。データモデルの 1 要素を表現するコンポーネントに、モックを分割して落とし込んでみましょう。 From 01eac00f7b413c41f0febf88b144acf6d80cf38e Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:39:45 +0900 Subject: [PATCH 17/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index d107e0926..939a1db70 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -37,7 +37,7 @@ React のすばらしい特長がいくつもありますが、あなたがど しかし、どうやって単一のコンポーネントに括るべき範囲を見つけられるのでしょうか。ちょうど、新しい関数やオブジェクトをいつ作るのかを決めるときと、同じ手法が使えます。このような手法のひとつに、[単一責任の原則 (single responsibility principle)](https://en.wikipedia.org/wiki/Single_responsibility_principle) があり、これはすなわち、ひとつのコンポーネントは理想的にはひとつのことだけをするべきだということです。将来、コンポーネントが肥大化してしまった場合には、小さなコンポーネントに分割するべきです。 -皆さんがこれまで JSON で作ったデータモデルをユーザーに向けて表示してきた経験から、モデルを正しく構築できていれば、UI（つまりコンポーネントの構造）へのデータマッピングも上手くいくであろうことは想像に難くないでしょう。これは、UI とデータモデルが同じ **情報の構造** を持つ傾向があるためです。このおかげで、UI をコンポーネントに切り分ける作業は自明なものになりがちです。データモデルの 1 要素を表現するコンポーネントに、モックを分割して落とし込んでみましょう。 +JSON のデータモデルをユーザーに向けて表示することはよくありますので、モデルを正しく構築できているか、UI（つまりコンポーネントの構造）へのマッピングがうまくいっているか、といったことを、皆さんはよく判断できます。これは、UI とデータモデルが同じ **情報の構造** を持つ傾向があるためです。このおかげで、UI をコンポーネントに切り分ける作業は自明なものになりがちです。モックを分割して、データモデルの厳密に一部分だけを表現するコンポーネントへと落とし込みましょう。 ![コンポーネント図](../images/blog/thinking-in-react-components.png) From 94311c2af0e73bb72011491a49819e0db6efdab8 Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:41:18 +0900 Subject: [PATCH 18/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 939a1db70..5ebe0bb82 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -60,7 +60,7 @@ JSON のデータモデルをユーザーに向けて表示することはよく * `ProductCategoryRow` * `ProductRow` -## Step 2：Reactで静的なバージョンを作成する +## Step 2: Reactで静的なバージョンを作成する

See the Pen Thinking In React: Step 2 on CodePen.

From 2c7af1983ab0563e6809376a8e474ceaf18d8b5d Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:41:38 +0900 Subject: [PATCH 19/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 5ebe0bb82..cb3aec92e 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -50,7 +50,7 @@ JSON のデータモデルをユーザーに向けて表示することはよく 4. **`ProductCategoryRow`（水色）：** *カテゴリ* を見出しとして表示する 5. **`ProductRow`（赤色）：** 各 *商品* を 1 行で表示する -`ProductTable` を見てみると、表のヘッダー（「Name」や「Price」のラベルを含む）が自身のコンポーネントを持っていないことがわかります。これは好みの問題で、コンポーネントにするかしないかは両論あります。今回の例でいえば、ヘッダーを `ProductTable` の一部にしたのは、 *データの集合* を描画するという `ProductTable` の責務の一環として適切だったからです。しかしながら、将来ヘッダーが肥大化して複雑になった場合（例えばソート機能を追加した場合など）は、 `ProductTableHeader` のようなコンポーネントにするのが適切になるでしょう。 +`ProductTable` を見てみると、表のヘッダー（「Name」や「Price」のラベルを含む）が単独のコンポーネントになっていないことがわかります。これは好みの問題で、コンポーネントにするかしないかは両論あります。今回の例でいえば、ヘッダーを `ProductTable` の一部にしたのは、 *データの集合* を描画するという `ProductTable` の責務の一環として適切だったからです。しかしながら、将来ヘッダーが肥大化して複雑になった場合（例えばソート機能を追加した場合など）は、`ProductTableHeader` のようなコンポーネントにするのが適切になるでしょう。 さて、モック内にコンポーネントを定義できましたので、階層構造に並べてみましょう。簡単なことです。モックで他のコンポーネントの中にあるコンポーネントを、階層構造でも子要素として配置すればいいのです。次のようになります。 From 61d4ccdab3339255435b5d2e8eca4b919c9c00b0 Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:42:16 +0900 Subject: [PATCH 20/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index cb3aec92e..5e288bd70 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -136,7 +136,7 @@ UI をインタラクティブなものにするにあたり、UI を構築す ここまでで、props と state が階層構造を流れ落ちていく関数として、正しく描画を行うアプリを作ることができました。それでは、別の方向のデータフローもサポートしてみましょう。階層構造の奥深くにあるフォームのコンポーネントが、`FilterableProductTable` にある state を更新できるようにするのです。 -React はデータフローを明示的にしてプログラムの動作を理解しやすくするためのものですが、従来の双方向データバインディングよりも少し手を動かす必要があります。 +React ではデータフローが明示的になりプログラムの動作が理解しやすくなりますが、従来の双方向データバインディングよりも少しタイプ量が増えてはしまいます。 試しに、現在のバージョンのサンプルで文字を打ち込んだり、チェックボックスを切り替えてみると、React がその入力を無視することがわかります。これは意図的な挙動で、`input` の `value` props が、常に `FilterableProductTable` から渡された `state` と同じ値になるようにセットしてあるのです。 From 373763fe63e764b27aaef7bfaa063d17c6b281c7 Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:42:36 +0900 Subject: [PATCH 21/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 5e288bd70..9e50619d7 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -130,7 +130,7 @@ UI をインタラクティブなものにするにあたり、UI を構築す これで、このアプリがどんな振る舞いをするのか見られるようになってきました。`filterText` に `"ball"` と入力した状態でアプリを更新すると、データの表が正しく更新されたことが確認できるはずです。 -## Step 5：逆方向のデータフローを追加する +## Step 5: 逆方向のデータフローを追加する

See the Pen Thinking In React: Step 5 on CodePen.

From 67bdce2bdf2062ed7f4fc3ef02392de4c0942d89 Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:42:55 +0900 Subject: [PATCH 22/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 9e50619d7..20cb8219e 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -52,7 +52,7 @@ JSON のデータモデルをユーザーに向けて表示することはよく `ProductTable` を見てみると、表のヘッダー（「Name」や「Price」のラベルを含む）が単独のコンポーネントになっていないことがわかります。これは好みの問題で、コンポーネントにするかしないかは両論あります。今回の例でいえば、ヘッダーを `ProductTable` の一部にしたのは、 *データの集合* を描画するという `ProductTable` の責務の一環として適切だったからです。しかしながら、将来ヘッダーが肥大化して複雑になった場合（例えばソート機能を追加した場合など）は、`ProductTableHeader` のようなコンポーネントにするのが適切になるでしょう。 -さて、モック内にコンポーネントを定義できましたので、階層構造に並べてみましょう。簡単なことです。モックで他のコンポーネントの中にあるコンポーネントを、階層構造でも子要素として配置すればいいのです。次のようになります。 +さて、モック内にコンポーネントを特定できましたので、階層構造に並べてみましょう。簡単なことです。モックで他のコンポーネントの中にあるコンポーネントを、階層構造でも子要素として配置すればいいのです。次のようになります。 * `FilterableProductTable` * `SearchBar` From 4d6fa38006e0608a9bd7784e4232a10c3c79e7a8 Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:43:24 +0900 Subject: [PATCH 23/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 20cb8219e..5c3d49b8d 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -67,7 +67,7 @@ JSON のデータモデルをユーザーに向けて表示することはよく さて、コンポーネントの階層構造が決まったので、アプリの実装に取り掛かりましょう。最初は、データモデルを使用して UI の描画だけを行い、ユーザーからの操作はできないというバージョンを作るのが、もっとも簡単でしょう。なぜ最初から操作できるバージョンを作らないのでしょうか。多くの場合、静的な（操作できない）バージョンを作る際には、タイピングする量が多い代わりに悩むことが少ない傾向があります。逆に、操作できるように改修するときには、悩ましいことが多い代わりにタイピングの量は少ない傾向があります。そういった理由から、先に操作できないバージョンを作ります。 -データモデルを描画するだけの機能を持った、静的なバージョンのアプリを作る際には、再利用可能なコンポーネントを組み合わせて、それらに *props* を通じてデータを渡す形で、自分のコンポーネントを組み上げていきたいですよね。*props* は親から子へとデータを渡すための手段です。もし、あなたが *state* に慣れ親しんでいる場合でも、今回の静的なバージョンを作る上では**一切 state を使わないでください。** state はユーザー操作や時間経過などで動的に変化するデータを扱うために確保されている機能です。今回のアプリは静的なバージョンなので、stateは必要ありません。 +データモデルを描画するだけの機能を持った静的なバージョンのアプリを作る際には、他のコンポーネントを再利用しつつそれらに *props* を通じてデータを渡す形で、自分のコンポーネントを組み上げていきましょう。*props* は親から子へとデータを渡すための手段です。もし、あなたが *state* に慣れ親しんでいる場合でも、今回の静的なバージョンを作る上では**一切 state を使わないでください。**state はユーザー操作や時間経過などで動的に変化するデータを扱うために確保されている機能です。今回のアプリは静的なバージョンなので、state は必要ありません。 コンポーネントはトップダウンで作っても、ボトムアップで作っても問題ありません。 つまり、高い階層にあるコンポーネント（例えば `FilterableProductTable`）から作り始めても、低い階層にあるコンポーネント（`ProductRow` など）から作り始めても、どちらでもいいのです。身近な話題に置き換えて考えてみると、システム開発プロジェクトの進行は、多くの場合トップダウンで進めたほうがやりやすいですが、巨大なプロジェクトなら、ボトムアップで開発を進めるたびに自動テストを書いていったほうがやりやすい、といった話題が近いかもしれません。 From 8aabf35b6fdbdb136603653071c86d055c3e7833 Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:43:43 +0900 Subject: [PATCH 24/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 5c3d49b8d..f208b92c6 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -142,7 +142,7 @@ React ではデータフローが明示的になりプログラムの動作が それでは、どんな挙動になってほしいのかを考えてみましょう。ユーザーがフォームを変更するたびに、ユーザー入力を反映するように state を更新したいですね。コンポーネントの state を更新できるのは自分自身だけであるべきなので、 `FilterableProductTable` は `SearchBar` にコールバックを渡して、state を更新したいときにコールバックを実行してもらうようにします。入力のたびに呼び出される `onChange` イベントを利用するとよいでしょう。このコールバックを実行された `FilterableProductTable` は、`setState()` を呼び出し、その結果としてアプリが更新されます。 -これは複雑に思えるかもしれませんが、ほんの数行のコードです。 そして、これらはデータがアプリの中をどのように流れているのかを、明確に示しているのです。 +これは複雑に思えるかもしれませんが、ほんの数行のコードです。そして、これらはデータがアプリの中をどのように流れているのかを、明確に示しているのです。 ## 終わりに From db0e67acc904f0ac7ca00d37e7177e464d7a97a2 Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:44:11 +0900 Subject: [PATCH 25/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index f208b92c6..60a0c3895 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -146,4 +146,4 @@ React ではデータフローが明示的になりプログラムの動作が ## 終わりに -うまくいけば、これで React を使ってコンポーネントやアプリケーションを構築する方法について考えることができるようになります。それはもしかしたら、あなたのこれまでのやり方よりも、多くのコードを書くことになるかもしれません。しかしながら、コードは書くよりも読むことのほうが多いことや、モジュール化されていて明示的であるコードは非常に読みやすいということを思い出してください。大規模なコンポーネントのライブラリを構築し始めると、この明示性やモジュール化しやすさを高く評価することになり、コードを再利用することになり、あなたが書くコードの行数は減っていくのです。:) +これで React を使ってコンポーネントやアプリケーションを構築するときの考え方が身に付いたのではないでしょうか。それはもしかしたら、あなたのこれまでのやり方よりも、多くのコードを書くことになるかもしれません。しかしながら、コードは書くよりも読むことのほうが多いこと、そしてモジュール化されていて明示的であるコードは非常に読みやすいということを思い出してください。大規模なコンポーネントのライブラリを構築し始めると、この明示性やモジュール化しやすさのありがたみが分かり始めます。そしてコードを再利用できるようになるにつれて、あなたが書くコードの行数は減っていくのです。:) From b02b0a0a3133855c03c28a72037fb4d149a3946b Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:44:45 +0900 Subject: [PATCH 26/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 60a0c3895..47885e64d 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -69,7 +69,7 @@ JSON のデータモデルをユーザーに向けて表示することはよく データモデルを描画するだけの機能を持った静的なバージョンのアプリを作る際には、他のコンポーネントを再利用しつつそれらに *props* を通じてデータを渡す形で、自分のコンポーネントを組み上げていきましょう。*props* は親から子へとデータを渡すための手段です。もし、あなたが *state* に慣れ親しんでいる場合でも、今回の静的なバージョンを作る上では**一切 state を使わないでください。**state はユーザー操作や時間経過などで動的に変化するデータを扱うために確保されている機能です。今回のアプリは静的なバージョンなので、state は必要ありません。 -コンポーネントはトップダウンで作っても、ボトムアップで作っても問題ありません。 つまり、高い階層にあるコンポーネント（例えば `FilterableProductTable`）から作り始めても、低い階層にあるコンポーネント（`ProductRow` など）から作り始めても、どちらでもいいのです。身近な話題に置き換えて考えてみると、システム開発プロジェクトの進行は、多くの場合トップダウンで進めたほうがやりやすいですが、巨大なプロジェクトなら、ボトムアップで開発を進めるたびに自動テストを書いていったほうがやりやすい、といった話題が近いかもしれません。 +コンポーネントはトップダウンで作っても、ボトムアップで作っても問題ありません。 つまり、高い階層にあるコンポーネント（例えば `FilterableProductTable`）から作り始めても、低い階層にあるコンポーネント（`ProductRow` など）から作り始めても、どちらでもいいのです。シンプルなアプリでは通常トップダウンで作った方が楽ですが、大きなプロジェクトでは開発をしながらテストを書き、ボトムアップで進める方がより簡単です。 最後に、再利用可能な、データモデルを描画するためのコンポーネントで作るライブラリについて考えてみましょう。今回のアプリは静的なバージョンなので、コンポーネントは `render()` メソッドだけを持つことになります。階層構造の中で最上位のコンポーネント（`FilterableProductTable`）が、データモデルを props として受け取ることになるでしょう。一度アプリを表示した後、あなたが元となるデータモデルを更新して再度 `ReactDOM.render()` を呼び出すと、UI が更新されることになります。このやり方なら、複雑なことをしていないので、UI がどのように更新されて、どこを変更すればよいか、容易に理解できることでしょう。React の**単方向データフロー**（あるいは*単方向バインディング*）は、すべてをモジュール化し、高速化します。 From eb5b068ecf668af0b0c73cc6a64604fa98dd132c Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:45:11 +0900 Subject: [PATCH 27/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 47885e64d..d654ded32 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -71,7 +71,7 @@ JSON のデータモデルをユーザーに向けて表示することはよく コンポーネントはトップダウンで作っても、ボトムアップで作っても問題ありません。 つまり、高い階層にあるコンポーネント（例えば `FilterableProductTable`）から作り始めても、低い階層にあるコンポーネント（`ProductRow` など）から作り始めても、どちらでもいいのです。シンプルなアプリでは通常トップダウンで作った方が楽ですが、大きなプロジェクトでは開発をしながらテストを書き、ボトムアップで進める方がより簡単です。 -最後に、再利用可能な、データモデルを描画するためのコンポーネントで作るライブラリについて考えてみましょう。今回のアプリは静的なバージョンなので、コンポーネントは `render()` メソッドだけを持つことになります。階層構造の中で最上位のコンポーネント（`FilterableProductTable`）が、データモデルを props として受け取ることになるでしょう。一度アプリを表示した後、あなたが元となるデータモデルを更新して再度 `ReactDOM.render()` を呼び出すと、UI が更新されることになります。このやり方なら、複雑なことをしていないので、UI がどのように更新されて、どこを変更すればよいか、容易に理解できることでしょう。React の**単方向データフロー**（あるいは*単方向バインディング*）は、すべてをモジュール化し、高速化します。 +ここまでのステップを終えると、データモデルを描画する再利用可能なコンポーネントのライブラリが手に入ります。このアプリは静的なバージョンなので、コンポーネントは `render()` メソッドだけを持つことになります。階層構造の中で最上位のコンポーネント（`FilterableProductTable`）が、データモデルを props として受け取ることになるでしょう。元となるデータモデルを更新して再度 `ReactDOM.render()` を呼び出すと、UI が更新されることになります。このやり方なら、複雑なことをしていないので、UI がどのように更新されて、どこを変更すればよいか、容易に理解できることでしょう。React の**単方向データフロー**（あるいは*単方向バインディング*）により、すべてがモジュール化された高速な状態で保たれます。 このステップを実施する上で助けが必要な場合は、[React ドキュメント](/docs/)を参照してください。 From 8a756700c39bb25be64a9a23c47838a27989bfbd Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:45:38 +0900 Subject: [PATCH 28/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index d654ded32..6c6bf75f4 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -79,7 +79,7 @@ JSON のデータモデルをユーザーに向けて表示することはよく React には 2 種類の「モデル」データが存在します。 props と state です。このふたつの相違を理解するのは重要なことです。もしあなたがこれらの違いについての知識に自信がない場合は、[公式の React ドキュメント](/docs/interactivity-and-dynamic-uis.html)に目を通すとよいでしょう。 -## Step 3：UI が持つ state の最小構成を明確にする +## Step 3: UI 状態を表現する必要かつ十分な state を決定する UI をインタラクティブなものにするにあたり、UI を構築する元となっているデータモデルを更新できるようにしておきたいですね。React なら **state** を使うことで容易に実現できます。 From 5e35fd3e6d6e9bc1835b0c87e3a85758a68441a3 Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:45:57 +0900 Subject: [PATCH 29/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 6c6bf75f4..98840bd3a 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -85,7 +85,7 @@ UI をインタラクティブなものにするにあたり、UI を構築す 適切に開発を進めていくにあたり、そのアプリに求められている更新可能な状態の最小構成を、最初に考えておいたほうがよいでしょう。ここで重要なのは、[DRY（*Don't Repeat Yourself*）](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)の原則です。アプリケーションが必要としている最小限の状態を把握しておき、他に必要なものが出てきたら、そのとき計算すればよいのです。例を挙げてみましょう。もしあなたが TODO リストを作ることになったら、TODO の各項目を配列で保持しますよね。個数のカウント用に、別の状態変数を持ったりはしません。その代わりに、TODO の項目数を表示したいのであれば、単純に配列の length を使えばよいのです。 -今回のサンプルアプリを形作るデータについて考えてみましょう。次のようなデータがあります。 +今回のサンプルアプリを形作るすべてのデータについて考えてみましょう。次のようなデータがあります。 * 元となる商品のリスト * ユーザーが入力した検索文字列 From eaf3083bf7ce3cb76bbb63d7e358f0db21e2616d Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:46:16 +0900 Subject: [PATCH 30/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 98840bd3a..7c0b167bb 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -105,7 +105,7 @@ UI をインタラクティブなものにするにあたり、UI を構築す * ユーザーが入力した検索文字列 * チェックボックスの値 -## Step 4：state をどこに配置するべきなのかを明確にする +## Step 4: state をどこに配置するべきなのかを明確にする

See the Pen Thinking In React: Step 4 on CodePen.

From f7be5224425393e9eb0f509811e368aa9e729f08 Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:46:33 +0900 Subject: [PATCH 31/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 7c0b167bb..c8562eec4 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -92,7 +92,7 @@ UI をインタラクティブなものにするにあたり、UI を構築す * チェックボックスの値 * フィルタ済みの商品のリスト -それぞれについて見ていき、どれが state になりうるのかを考えてみます。各データについて、 3 つの質問をするだけです。 +それぞれについて見ていき、どれが state になりうるのかを考えてみます。各データについて、3 つの質問をするだけです。 1. 親から props を通じて与えられたデータでしょうか？　もしそうなら、それは state ではありません 2. 時間経過で変化しないままでいるデータでしょうか？　もしそうなら、それは state ではありません From c315e2b915df8a8e305ca6f95679fa6907932ed3 Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:46:53 +0900 Subject: [PATCH 32/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index c8562eec4..7d93f6060 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -118,7 +118,7 @@ UI をインタラクティブなものにするにあたり、UI を構築す * その state を使って表示を行う、すべてのコンポーネントを確認する * 共通の親コンポーネントを見つける（その階層構造の中で、ある state を必要としているすべてのコンポーネントの真上にある単一のコンポーネントのことです） * 共通の親コンポーネントか、その階層構造でさらに上位の別のコンポーネントが state を持っているべきである - * もし state を持つにふさわしいコンポーネントを見つけられなかった場合は、state を保持するためのコンポーネントを作り、そこに state を置いた上で、階層構造の中ですでに見つけていた共通の親コンポーネントの上に配置する + * もし state を持つにふさわしいコンポーネントを見つけられなかった場合は、state を保持するためだけの新しいコンポーネントを作り、階層構造の中ですでに見つけておいた共通の親コンポーネントの上に配置する それでは、この戦術をサンプルアプリにも適用してみましょう。 From 1f9824f6c58d69286b3f61792eae3c258889120b Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:47:22 +0900 Subject: [PATCH 33/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 7d93f6060..01a9b271a 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -77,7 +77,7 @@ JSON のデータモデルをユーザーに向けて表示することはよく ### 幕間：Props vs State -React には 2 種類の「モデル」データが存在します。 props と state です。このふたつの相違を理解するのは重要なことです。もしあなたがこれらの違いについての知識に自信がない場合は、[公式の React ドキュメント](/docs/interactivity-and-dynamic-uis.html)に目を通すとよいでしょう。 +React には 2 種類の「モデル」データが存在します。props と state です。このふたつの相違を理解するのは重要なことです。違いについて自信がない場合は、[公式の React ドキュメント](/docs/interactivity-and-dynamic-uis.html)に目を通すとよいでしょう。 ## Step 3: UI 状態を表現する必要かつ十分な state を決定する From da0e7b79a39e5d41c9365335fa2a48bc3919f3d3 Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:48:33 +0900 Subject: [PATCH 34/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 01a9b271a..590f385ef 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -109,7 +109,7 @@ UI をインタラクティブなものにするにあたり、UI を構築す

See the Pen Thinking In React: Step 4 on CodePen.

-さて、state の最小構成が明確になりました。次は、どのコンポーネントを変化させるのか、そして*どのコンポーネントが state を持つのか*を明確にしましょう。 +さて、state の最小構成が明確になりました。次は、どのコンポーネントが state を変化させるのか、つまり state を*所有*するのかを明確にしましょう。 復習：React は、コンポーネントの階層構造をデータが下っていく、単方向データフローで成り立っています。もしかすると、どのコンポーネントがどんな state を持つべきなのかが、すぐにはわからないかもしれません。**これは、初学者がReactへの理解を深める上で、最も難しい問題になりがちなところ** なので、ステップを踏みながら理解していきましょう。 From c3edc26ab94f15fb078922d49def2aaa915fafd9 Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:48:55 +0900 Subject: [PATCH 35/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 590f385ef..350bf0db9 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -111,7 +111,7 @@ UI をインタラクティブなものにするにあたり、UI を構築す さて、state の最小構成が明確になりました。次は、どのコンポーネントが state を変化させるのか、つまり state を*所有*するのかを明確にしましょう。 -復習：React は、コンポーネントの階層構造をデータが下っていく、単方向データフローで成り立っています。もしかすると、どのコンポーネントがどんな state を持つべきなのかが、すぐにはわからないかもしれません。**これは、初学者がReactへの理解を深める上で、最も難しい問題になりがちなところ** なので、ステップを踏みながら理解していきましょう。 +復習：React は、コンポーネントの階層構造をデータが流れ落ちていく、単方向データフローで成り立っています。もしかすると、どのコンポーネントがどんな state を持つべきなのかが、すぐにはわからないかもしれません。**これは、初学者が React への理解を深める上で、最も難しい問題になりがちなところ** なので、ステップを踏みながら理解していきましょう。 アプリの各 state について、次の各項目を確認していきます。 From 5a822e5f2fd06c42963de00adca73a22b8c49d03 Mon Sep 17 00:00:00 2001 From: Soichiro Miki Date: Tue, 5 Feb 2019 11:49:11 +0900 Subject: [PATCH 36/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 350bf0db9..0c0756b49 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -116,7 +116,7 @@ UI をインタラクティブなものにするにあたり、UI を構築す アプリの各 state について、次の各項目を確認していきます。 * その state を使って表示を行う、すべてのコンポーネントを確認する - * 共通の親コンポーネントを見つける（その階層構造の中で、ある state を必要としているすべてのコンポーネントの真上にある単一のコンポーネントのことです） + * 共通の親コンポーネントを見つける（その階層構造の中で、ある state を必要としているすべてのコンポーネントの上位にある単一のコンポーネントのことです） * 共通の親コンポーネントか、その階層構造でさらに上位の別のコンポーネントが state を持っているべきである * もし state を持つにふさわしいコンポーネントを見つけられなかった場合は、state を保持するためだけの新しいコンポーネントを作り、階層構造の中ですでに見つけておいた共通の親コンポーネントの上に配置する From 670bddf6ef9884a067877f48199bf9221bcdde0d Mon Sep 17 00:00:00 2001 From: Yukiya Nakagawa Date: Tue, 5 Feb 2019 13:37:56 +0900 Subject: [PATCH 37/40] docs(thinking-in-react): Accept suggested change --- content/docs/thinking-in-react.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 0c0756b49..1bc41f1d8 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -65,7 +65,7 @@ JSON のデータモデルをユーザーに向けて表示することはよく

See the Pen Thinking In React: Step 2 on CodePen.

-さて、コンポーネントの階層構造が決まったので、アプリの実装に取り掛かりましょう。最初は、データモデルを使用して UI の描画だけを行い、ユーザーからの操作はできないというバージョンを作るのが、もっとも簡単でしょう。なぜ最初から操作できるバージョンを作らないのでしょうか。多くの場合、静的な（操作できない）バージョンを作る際には、タイピングする量が多い代わりに悩むことが少ない傾向があります。逆に、操作できるように改修するときには、悩ましいことが多い代わりにタイピングの量は少ない傾向があります。そういった理由から、先に操作できないバージョンを作ります。 +さて、コンポーネントの階層構造が決まったので、アプリの実装に取り掛かりましょう。最初は、データモデルを受け取って UI の描画だけを行い、ユーザーからの操作はできないというバージョンを作るのが、もっとも簡単でしょう。表示の実装とユーザ操作の実装を切り離しておくことは重要です。静的な（操作できない）バージョンを作る際には、タイプ量が多い代わりに考えることが少なく、ユーザ操作を実装するときには、考えることが多い代わりにタイプ量は少ないからです。なぜそうなのかは後で説明します データモデルを描画するだけの機能を持った静的なバージョンのアプリを作る際には、他のコンポーネントを再利用しつつそれらに *props* を通じてデータを渡す形で、自分のコンポーネントを組み上げていきましょう。*props* は親から子へとデータを渡すための手段です。もし、あなたが *state* に慣れ親しんでいる場合でも、今回の静的なバージョンを作る上では**一切 state を使わないでください。**state はユーザー操作や時間経過などで動的に変化するデータを扱うために確保されている機能です。今回のアプリは静的なバージョンなので、state は必要ありません。 @@ -81,9 +81,9 @@ React には 2 種類の「モデル」データが存在します。props と s ## Step 3: UI 状態を表現する必要かつ十分な state を決定する -UI をインタラクティブなものにするにあたり、UI を構築する元となっているデータモデルを更新できるようにしておきたいですね。React なら **state** を使うことで容易に実現できます。 +UI をインタラクティブなものにするためには元となっているデータモデルを更新できる必要があります。これは React なら **state** を使うことで容易に実現できます。 -適切に開発を進めていくにあたり、そのアプリに求められている更新可能な状態の最小構成を、最初に考えておいたほうがよいでしょう。ここで重要なのは、[DRY（*Don't Repeat Yourself*）](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)の原則です。アプリケーションが必要としている最小限の状態を把握しておき、他に必要なものが出てきたら、そのとき計算すればよいのです。例を挙げてみましょう。もしあなたが TODO リストを作ることになったら、TODO の各項目を配列で保持しますよね。個数のカウント用に、別の状態変数を持ったりはしません。その代わりに、TODO の項目数を表示したいのであれば、単純に配列の length を使えばよいのです。 +適切に開発を進めていくにあたり、そのアプリに求められている更新可能な状態の最小構成を、最初に考えておいたほうがよいでしょう。ここで重要なのは、[DRY (don't repeat yourself)](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)の原則です。アプリケーションが必要としている最小限の状態を把握しておき、他に必要なものが出てきたら、そのとき計算すればよいのです。例えば、TODO リストを作る場合、TODO の各項目を配列で保持するだけにし、個数のカウント用に別の state 変数を持たないようにします。その代わりに、TODO の項目数を表示したいのであれば、単純に配列の length を使えばよいのです。 今回のサンプルアプリを形作るすべてのデータについて考えてみましょう。次のようなデータがあります。 @@ -140,7 +140,7 @@ React ではデータフローが明示的になりプログラムの動作が 試しに、現在のバージョンのサンプルで文字を打ち込んだり、チェックボックスを切り替えてみると、React がその入力を無視することがわかります。これは意図的な挙動で、`input` の `value` props が、常に `FilterableProductTable` から渡された `state` と同じ値になるようにセットしてあるのです。 -それでは、どんな挙動になってほしいのかを考えてみましょう。ユーザーがフォームを変更するたびに、ユーザー入力を反映するように state を更新したいですね。コンポーネントの state を更新できるのは自分自身だけであるべきなので、 `FilterableProductTable` は `SearchBar` にコールバックを渡して、state を更新したいときにコールバックを実行してもらうようにします。入力のたびに呼び出される `onChange` イベントを利用するとよいでしょう。このコールバックを実行された `FilterableProductTable` は、`setState()` を呼び出し、その結果としてアプリが更新されます。 +それでは、どんな挙動になってほしいのかを考えてみましょう。ユーザーがフォームを変更するたびに、ユーザー入力を反映するように state を更新したいですね。コンポーネントの state を更新できるのは自分自身だけであるべきなので、 `FilterableProductTable` は `SearchBar` にコールバックを渡しておいて、state を更新したいときに実行してもらうようにします。入力のたびに呼び出される `onChange` イベントを利用するとよいでしょう。このコールバックを実行された `FilterableProductTable` は、`setState()` を呼び出し、その結果としてアプリが更新されます。 これは複雑に思えるかもしれませんが、ほんの数行のコードです。そして、これらはデータがアプリの中をどのように流れているのかを、明確に示しているのです。 From 7695b95f47221b62aad7769a759d02d93ef22cc9 Mon Sep 17 00:00:00 2001 From: Yukiya Nakagawa Date: Tue, 5 Feb 2019 13:38:30 +0900 Subject: [PATCH 38/40] docs(thinking-in-react): Add issue number --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 1bc41f1d8..515e23a3c 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -42,7 +42,7 @@ JSON のデータモデルをユーザーに向けて表示することはよく ![コンポーネント図](../images/blog/thinking-in-react-components.png) 5 種類のコンポーネントがこのシンプルなアプリの中にあることが見て取れます。それぞれの解説の中で、データを表すものについては斜体にしました。 - + 1. **`FilterableProductTable`（オレンジ色）：** このサンプル全体を含む 2. **`SearchBar`（青色）：** すべての *ユーザー入力* を受け付ける From eb2efd228f6167a0109ee9812c9098cc172fde81 Mon Sep 17 00:00:00 2001 From: Yukiya Nakagawa Date: Tue, 5 Feb 2019 13:39:13 +0900 Subject: [PATCH 39/40] =?UTF-8?q?docs(thinking-in-react):=20=E3=82=BF?= =?UTF-8?q?=E3=82=A4=E3=83=88=E3=83=AB=E3=82=92=E3=80=8CReact=E3=81=AE?= =?UTF-8?q?=E6=B5=81=E5=84=80=E3=80=8D=E3=81=AB=E3=81=97=E3=81=A6=E3=81=BF?= =?UTF-8?q?=E3=81=BE=E3=81=97=E3=81=9F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 515e23a3c..0bcf4d0c7 100644 --- a/content/docs/thinking-in-react.md +++ b/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' From dac01c6f00abba237eac5e83388a0f1e792933df Mon Sep 17 00:00:00 2001 From: Toru Kobayashi Date: Tue, 5 Feb 2019 18:23:56 +0900 Subject: [PATCH 40/40] docs(thinking-in-react): Accept suggested change Co-Authored-By: Nkzn --- content/docs/thinking-in-react.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/docs/thinking-in-react.md b/content/docs/thinking-in-react.md index 0bcf4d0c7..eb97b34f8 100644 --- a/content/docs/thinking-in-react.md +++ b/content/docs/thinking-in-react.md @@ -65,7 +65,7 @@ JSON のデータモデルをユーザーに向けて表示することはよく

See the Pen Thinking In React: Step 2 on CodePen.

-さて、コンポーネントの階層構造が決まったので、アプリの実装に取り掛かりましょう。最初は、データモデルを受け取って UI の描画だけを行い、ユーザーからの操作はできないというバージョンを作るのが、もっとも簡単でしょう。表示の実装とユーザ操作の実装を切り離しておくことは重要です。静的な（操作できない）バージョンを作る際には、タイプ量が多い代わりに考えることが少なく、ユーザ操作を実装するときには、考えることが多い代わりにタイプ量は少ないからです。なぜそうなのかは後で説明します +さて、コンポーネントの階層構造が決まったので、アプリの実装に取り掛かりましょう。最初は、データモデルを受け取って UI の描画だけを行い、ユーザーからの操作はできないというバージョンを作るのが、もっとも簡単でしょう。表示の実装とユーザ操作の実装を切り離しておくことは重要です。静的な（操作できない）バージョンを作る際には、タイプ量が多い代わりに考えることが少なく、ユーザ操作を実装するときには、考えることが多い代わりにタイプ量は少ないからです。なぜそうなのかは後で説明します。 データモデルを描画するだけの機能を持った静的なバージョンのアプリを作る際には、他のコンポーネントを再利用しつつそれらに *props* を通じてデータを渡す形で、自分のコンポーネントを組み上げていきましょう。*props* は親から子へとデータを渡すための手段です。もし、あなたが *state* に慣れ親しんでいる場合でも、今回の静的なバージョンを作る上では**一切 state を使わないでください。**state はユーザー操作や時間経過などで動的に変化するデータを扱うために確保されている機能です。今回のアプリは静的なバージョンなので、state は必要ありません。