diff --git a/src/content/learn/thinking-in-react.md b/src/content/learn/thinking-in-react.md index 23d4beb3f..bff73589d 100644 --- a/src/content/learn/thinking-in-react.md +++ b/src/content/learn/thinking-in-react.md @@ -1,18 +1,18 @@ --- -title: Thinking in React +title: React の流儀 --- -React can change how you think about the designs you look at and the apps you build. When you build a user interface with React, you will first break it apart into pieces called *components*. Then, you will describe the different visual states for each of your components. Finally, you will connect your components together so that the data flows through them. In this tutorial, we’ll guide you through the thought process of building a searchable product data table with React. +React は、あなたが設計を考える方法やアプリを構築する方法を変化させます。React でユーザインターフェースを構築する際には、まず UI を*コンポーネント*と呼ばれる部品に分割します。次に、各コンポーネントのさまざまな視覚的状態を記述します。最後に、複数のコンポーネントを接続し、それらの間をデータが流れるようにします。このチュートリアルでは、React を使って検索可能な商品データテーブルを作成する際の思考プロセスについて説明します。 -## Start with the mockup {/*start-with-the-mockup*/} +## モックアップから始めよう {/*start-with-the-mockup*/} -Imagine that you already have a JSON API and a mockup from a designer. +すでに、JSON API が実装済みで、デザイナからもモックアップがもらえているとしましょう。 -The JSON API returns some data that looks like this: +JSON API は以下のようなデータを返します。 ```json [ @@ -25,25 +25,25 @@ The JSON API returns some data that looks like this: ] ``` -The mockup looks like this: +モックは次のような見た目だったとします。 -To implement a UI in React, you will usually follow the same five steps. +React で UI を実装する際には、通常以下のような 5 つのステップに従います。 -## Step 1: Break the UI into a component hierarchy {/*step-1-break-the-ui-into-a-component-hierarchy*/} +## ステップ 1：UI をコンポーネントの階層に分割する {/*step-1-break-the-ui-into-a-component-hierarchy*/} -Start by drawing boxes around every component and subcomponent in the mockup and naming them. If you work with a designer, they may have already named these components in their design tool. Ask them! +まず最初に行うのは、モックアップのすべてのコンポーネントとサブコンポーネントを四角で囲んで、それぞれに名前を付けていくことです。デザイナと一緒に仕事をしている場合は、彼らがデザインツールでこれらのコンポーネントにすでに名前を付けているかもしれませんので、話をしに行きましょう。 -Depending on your background, you can think about splitting up a design into components in different ways: +あなたの技術的バックグラウンドによって、デザインをコンポーネントに分割するとはどういうことなのか、いろいろな考え方ができるでしょう： -* **Programming**--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. -* **CSS**--consider what you would make class selectors for. (However, components are a bit less granular.) -* **Design**--consider how you would organize the design's layers. +* **プログラマ** -- 新しい関数やオブジェクトを作成するかどうかを決定するときと同じ手法を使いましょう。そのような手法のひとつに[単一責任の原則 (single responsibility principle)](https://en.wikipedia.org/wiki/Single_responsibility_principle) があります。つまり、1 つのコンポーネントは理想的には 1 つのことだけを行うべきだということです。もし大きくなってしまったら、より小さなサブコンポーネントに分解するべきです。 +* **CSS エンジニア** -- どの部分に対してクラスセレクタを作成するのか、と考えてみてください（ただし、コンポーネントの方が少し粒度が低めです）。 +* **デザイナ** -- デザインのレイヤをどのように整理するかを考えてください。 -If your JSON is well-structured, you'll often find that it naturally maps to the component structure of your UI. That's because UI and data models often have the same information architecture--that is, the same shape. Separate your UI into components, where each component matches one piece of your data model. +JSON がうまく構造化されている場合、それが UI のコンポーネント構造に自然に対応していることがよくあります。それは、UI とデータモデルが同じ情報アーキテクチャ、つまり同じ形状を持っていることが多いためです。1 つのコンポーネントがデータモデルの 1 つの部分に対応するような形で、UI をコンポーネントに分割していきましょう。 -There are five components on this screen: +この画面には 5 つのコンポーネントがあることがわかります。 @@ -51,19 +51,19 @@ There are five components on this screen: -1. `FilterableProductTable` (grey) contains the entire app. -2. `SearchBar` (blue) receives the user input. -3. `ProductTable` (lavender) displays and filters the list according to the user input. -4. `ProductCategoryRow` (green) displays a heading for each category. -5. `ProductRow` (yellow) displays a row for each product. +1. `FilterableProductTable`（灰色）はアプリ全体のコンテナ。 +2. `SearchBar`（青）はユーザ入力を受け取る。 +3. `ProductTable`（紫）はユーザ入力に従ってリストを表示およびフィルタリングする。 +4. `ProductCategoryRow`（緑）はカテゴリごとの見出しを表示する。 +5. `ProductRow`（黄）は個々の製品に対応する行を表示する。 -If you look at `ProductTable` (lavender), 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 you could go either way. For this example, it is a part of `ProductTable` because it appears inside the `ProductTable`'s list. However, if this header grows to be complex (e.g., if you add sorting), you can move it into its own `ProductTableHeader` component. +`ProductTable`（紫）を見ると、（"Name" と "Price" というラベルがある）テーブルヘッダ部分が、専用のコンポーネントになっていないことに気付くでしょう。これは好みの問題であり、どちらであっても構いません。今回の例ではヘッダは商品テーブル内に表示するものであるため、`ProductTable` の一部としています。ただし、このヘッダが複雑になる場合（例えばソート機能を追加する場合）、専用の `ProductTableHeader` コンポーネントに移動してもよいでしょう。 -Now that you've identified the components in the mockup, arrange them into a hierarchy. Components that appear within another component in the mockup should appear as a child in the hierarchy: +モックアップ内にあるコンポーネントを特定したら、それらを階層構造に整理します。モックアップで他のコンポーネントの中にあるコンポーネントを、階層構造でも子要素として配置すればいいのです。 * `FilterableProductTable` * `SearchBar` @@ -71,13 +71,13 @@ Now that you've identified the components in the mockup, arrange them into a hie * `ProductCategoryRow` * `ProductRow` -## Step 2: Build a static version in React {/*step-2-build-a-static-version-in-react*/} +## ステップ 2: React で静的なバージョンを作成する {/*step-2-build-a-static-version-in-react*/} -Now that you have your component hierarchy, it's time to implement your app. The most straightforward approach is to build a version that renders the UI from your data model without adding any interactivity... yet! It's often easier to build the static version first and add interactivity later. Building a static version requires a lot of typing and no thinking, but adding interactivity requires a lot of thinking and not a lot of typing. +これでコンポーネント階層ができたので、アプリの実装に取り掛かりましょう。最も分かりやすいアプローチは、インタラクティブな要素はまだ加えず、単にデータモデルから UI をレンダーするバージョンを作成することです。静的なバージョンを先に構築し、後からインタラクティブ性を追加する方が、多くの場合は簡単です。静的なバージョンを作成する間はタイプ量が多い代わりに考えることはほどんどなく、インタラクティブな要素を追加しようとするとタイプ量が少ない代わりに考えることが多くなります。 -To build a static version of your app that renders your data model, you'll want to build [components](/learn/your-first-component) that reuse other components and pass data using [props.](/learn/passing-props-to-a-component) Props are a way of passing data from parent to child. (If you're familiar with the concept of [state](/learn/state-a-components-memory), 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.) +データモデルをレンダーする静的バージョンのアプリを作成するにあたっては、[コンポーネント](/learn/your-first-component)を作成していく際に、他のコンポーネントを再利用しつつ [props](/learn/passing-props-to-a-component) 経由でそれらにデータを渡すようにします。props とは、親から子へとデータを渡すための手段です。（もし [state](/learn/state-a-components-memory) の概念に馴染みがある場合でも、この静的なバージョンを作成している間は state を一切使わないでください。state はインタラクティビティ、つまり時間とともに変化するデータのためにあるものです。今はアプリの静的なバージョンなので state は不要です。） -You can either build "top down" by starting with building the components higher up in the hierarchy (like `FilterableProductTable`) or "bottom up" by working from components lower down (like `ProductRow`). In simpler examples, it’s usually easier to go top-down, and on larger projects, it’s easier to go bottom-up. +「トップダウン」で高い階層にあるコンポーネント (`FilterableProductTable`) から構築を始めることも、「ボトムアップ」で低い階層にあるコンポーネント (`ProductRow`) から構築を始めることもできます。通常、単純な例ではトップダウンで作業する方が簡単であり、大規模なプロジェクトではボトムアップで進める方が簡単です。 @@ -195,85 +195,85 @@ td { -(If this code looks intimidating, go through the [Quick Start](/learn/) first!) +（このコードが難解に思える場合は、まず[クイックスタート](/learn/)を参照してください！） -After building your components, you'll have a library of reusable components that render your data model. Because this is a static app, the components will only return JSX. The component at the top of the hierarchy (`FilterableProductTable`) will take your data model as a prop. This is called _one-way data flow_ because the data flows down from the top-level component to the ones at the bottom of the tree. +コンポーネントの実装を終えると、データモデルをレンダーするための再利用可能なコンポーネントが一式揃ったということになります。これは静的なアプリですので、コンポーネントは JSX を返す以外のことはしていません。階層の一番上のコンポーネント (`FilterableProductTable`) が、データモデルを props として受け取っています。データがトップレベルのコンポーネントからツリーの下の方にあるコンポーネントに流れていくため、この構造を _単方向データフロー (one-way data flow)_ と呼びます。 -At this point, you should not be using any state values. That’s for the next step! +この段階では、state の値をまだ使わないでください。それは次のステップで行います！ -## Step 3: Find the minimal but complete representation of UI state {/*step-3-find-the-minimal-but-complete-representation-of-ui-state*/} +## ステップ 3：UI の状態を最小限かつ完全に表現する方法を見つける {/*step-3-find-the-minimal-but-complete-representation-of-ui-state*/} -To make the UI interactive, you need to let users change your underlying data model. You will use *state* for this. +UI をインタラクティブにするには、ユーザが背後にあるデータモデルを変更できるようにする必要があります。これには *state* というものを使用します。 -Think of state as the minimal set of changing data that your app needs to remember. The most important principle for structuring state is to keep it [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 on-demand. For example, if you're building a shopping list, you can store the items as an array in state. If you want to also display the number of items in the list, don't store the number of items as another state value--instead, read the length of your array. +state とは、アプリが記憶する必要のある、変化するデータの最小限のセットのことである、と考えましょう。state の構造を考える上で最も重要な原則は、[DRY（Don't Repeat Yourself; 繰り返しを避ける）](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)です。アプリケーションが必要とする状態に関する必要最小限の表現を見つけ出し、他のすべてのものは必要になったらその場で計算します。例えば、ショッピングリストを作成する場合、商品のリストを配列型の state として格納できます。リスト内の商品数も表示したいという場合は、その数を別の state 値として格納するのではなく、代わりに配列の length を読み取ればいいのです。 -Now think of all of the pieces of data in this example application: +この例のアプリケーションで使われるデータはどのようなものか考えましょう： -1. The original list of products -2. The search text the user has entered -3. The value of the checkbox -4. The filtered list of products +1. 元となる商品のリスト +2. ユーザが入力した検索文字列 +3. チェックボックスの値 +4. フィルタ済みの商品のリスト -Which of these are state? Identify the ones that are not: +これらのうちどれが state でしょうか？ state でないものを特定してください。 -* Does it **remain unchanged** over time? If so, it isn't state. -* Is it **passed in from a parent** via props? If so, it isn't state. -* **Can you compute it** based on existing state or props in your component? If so, it *definitely* isn't state! +* 時間が経っても**変わらない**ものですか？ そうであれば、state ではありません。 +* 親から props 経由で**渡される**ものですか？ そうであれば、state ではありません。 +* コンポーネント内にある既存の state や props に基づいて**計算可能な**データですか？ そうであれば、それは*絶対に* state ではありません！ -What's left is probably state. +残ったものがおそらく state です。 -Let's go through them one by one again: +もう一度、それぞれを見ていきましょう： -1. The original list of products is **passed in as props, so it's not state.** -2. The search text seems to be state since it changes over time and can't be computed from anything. -3. The value of the checkbox seems to be state since it changes over time and can't be computed from anything. -4. The filtered list of products **isn't state because it can be computed** by taking the original list of products and filtering it according to the search text and value of the checkbox. +1. 元の商品リストは **props として渡されるので、state ではありません**。 +2. 検索テキストは state のようです。それは時間が経つと変わりますし、何から計算することはできません。 +3. チェックボックスの値も state のようです。それは時間が経つと変わりますし、何から計算することはできません。 +4. フィルタリングされた商品のリストは、元の商品リストを検索テキストとチェックボックスの値に従ってフィルタリングすることで**計算できるため、state ではありません**。 -This means only the search text and the value of the checkbox are state! Nicely done! +つまり、検索テキストとチェックボックスの値だけが state だということです！ よくできました！ -#### Props vs State {/*props-vs-state*/} +#### props と state {/*props-vs-state*/} -There are two types of "model" data in React: props and state. The two are very different: +React には 2 種類の "モデル" データがあります。props と state です。両者は非常に異なります。 -* [**Props** are like arguments you pass](/learn/passing-props-to-a-component) to a function. They let a parent component pass data to a child component and customize its appearance. For example, a `Form` can pass a `color` prop to a `Button`. -* [**State** is like a component’s memory.](/learn/state-a-components-memory) It lets a component keep track of some information and change it in response to interactions. For example, a `Button` might keep track of `isHovered` state. +* [**props** は関数に渡す引数のようなものです](/learn/passing-props-to-a-component)。親コンポーネントから子コンポーネントにデータを渡し、その外観をカスタマイズするために使います。例えば、`Form` は `Button` に props として `color` を渡すことができます。 +* [**state** はコンポーネントのメモリのようなものです](/learn/state-a-components-memory)。コンポーネントが情報を追跡し、ユーザ操作に反応して変更できるようにします。例えば、`Button` は `isHovered` という state を保持するかもしれません。 -Props and state are different, but they work together. A parent component will often keep some information in state (so that it can change it), and *pass it down* to child components as their props. It's okay if the difference still feels fuzzy on the first read. It takes a bit of practice for it to really stick! +props と state は異なるものですが、それらは協調して働きます。親コンポーネントは state として情報を保持し（それを変更できるように）、その情報を子コンポーネントに props として*渡し*ます。1 度読んだだけでは違いがまだぼんやりと感じられるとしても問題ありません。少し練習することで完全に頭に入るようになります！ -## Step 4: Identify where your state should live {/*step-4-identify-where-your-state-should-live*/} +## ステップ 4：state を保持すべき場所を特定する {/*step-4-identify-where-your-state-should-live*/} -After identifying your app’s minimal state data, you need to identify which component is responsible for changing this state, or *owns* the state. Remember: React uses one-way data flow, passing data down the component hierarchy from parent to child component. It may not be immediately clear which component should own what state. This can be challenging if you’re new to this concept, but you can figure it out by following these steps! +アプリの最小限の state データを特定した後、この state を変更する責任を持つコンポーネント、つまり state を*所有する*コンポーネントを特定する必要があります。ここで思い出しましょう：React では単方向データフロー、つまり親から子コンポーネントへと階層を下る形でのみデータが渡されます。どのコンポーネントがどの状態を所有すべきか、すぐには分からないかもしれません。この概念が初めてであれば難しいかもしれませんが、以下のような手順に従って解決できます！ -For each piece of state in your application: +アプリケーション内の各 state について： -1. Identify *every* component that renders something based on that state. -2. Find their closest common parent component--a component above them all in the hierarchy. -3. Decide where the state should live: - 1. Often, you can put the state directly into their common parent. - 2. You can also put the state into some component above their common parent. - 3. If you can't find a component where it makes sense to own the state, create a new component solely for holding the state and add it somewhere in the hierarchy above the common parent component. +1. その state に基づいて何かをレンダーする*すべて*のコンポーネントを特定する。 +2. 階層内でそれらすべての上に位置する、最も近い共通の親コンポーネントを見つける。 +3. state がどこにあるべきかを決定する： + 1. 多くの場合、state をその共通の親に直接置くことができる。 + 2. state を、その共通の親のさらに上にあるコンポーネントに置くこともできる。 + 3. state を所有するのに適切なコンポーネントが見つからない場合は、state を保持するためだけの新しいコンポーネントを作成し、共通の親コンポーネントの階層の上のどこかに追加する。 -In the previous step, you found two pieces of state in this application: the search input text, and the value of the checkbox. In this example, they always appear together, so it makes sense to put them into the same place. +前のステップで、このアプリケーションに state が 2 つあることがわかりました。検索テキストとチェックボックスの値です。今回の例では、これらは常に一緒に表示されるので、同じ場所に置くことが理にかなっています。 -Now let's run through our strategy for them: +それではこの戦術をサンプルアプリにも適用してみましょう： -1. **Identify components that use state:** - * `ProductTable` needs to filter the product list based on that state (search text and checkbox value). - * `SearchBar` needs to display that state (search text and checkbox value). -1. **Find their common parent:** The first parent component both components share is `FilterableProductTable`. -2. **Decide where the state lives**: We'll keep the filter text and checked state values in `FilterableProductTable`. +1. **state を使用するコンポーネントの特定：** + * `ProductTable` は、これらの state （検索テキストとチェックボックスの値）に基づいて製品リストをフィルタリングする必要があります。 + * `SearchBar` は、これらの state（検索テキストとチェックボックスの値）を表示する必要があります。 +1. **共通の親を見つける：** 両方のコンポーネントに共通の最初の親コンポーネントは `FilterableProductTable` です。 +2. **state がどこにあるべきかを決定する：** フィルタ文字列とチェック状態の値を `FilterableProductTable` に保持することにします。 -So the state values will live in `FilterableProductTable`. +したがって、state の値は `FilterableProductTable` にあることになります。 -Add state to the component with the [`useState()` Hook.](/reference/react/useState) Hooks are special functions that let you "hook into" React. Add two state variables at the top of `FilterableProductTable` and specify their initial state: +コンポーネントに state を追加するには、[`useState()` フック](/reference/react/useState)を使用します。フックは、React に「接続 ("hook into")」するための特殊な関数です。`FilterableProductTable` の先頭に 2 つの state 変数を追加し、それらの初期値を指定します： ```js function FilterableProductTable({ products }) { @@ -281,7 +281,7 @@ function FilterableProductTable({ products }) { const [inStockOnly, setInStockOnly] = useState(false); ``` -Then, pass `filterText` and `inStockOnly` to `ProductTable` and `SearchBar` as props: +次に、`filterText` と `inStockOnly` を `ProductTable` と `SearchBar` に props として渡します： ```js
@@ -295,7 +295,7 @@ Then, pass `filterText` and `inStockOnly` to `ProductTable` and `SearchBar` as p
``` -You can start seeing how your application will behave. Edit the `filterText` initial value from `useState('')` to `useState('fruit')` in the sandbox code below. You'll see both the search input text and the table update: +だんだんとアプリケーションの動作が見えてきましたね。試しに以下のサンドボックスコードで `filterText` の初期値を、`useState('')` から `useState('fruit')` へと書き換えてみてください。検索テキストとテーブルの両方が更新されることがわかります： @@ -437,7 +437,7 @@ td { -Notice that editing the form doesn't work yet. There is a console error in the sandbox above explaining why: +まだフォームの編集ができないことに気付いたでしょう。その理由について、上のサンドボックスのコンソールエラーに説明があります。 @@ -445,7 +445,7 @@ You provided a \`value\` prop to a form field without an \`onChange\` handler. T -In the sandbox above, `ProductTable` and `SearchBar` read the `filterText` and `inStockOnly` props to render the table, the input, and the checkbox. For example, here is how `SearchBar` populates the input value: +上記のサンドボックスでは、`ProductTable` と `SearchBar` は `filterText` と `inStockOnly` という props を読み取り、テーブル、インプット、チェックボックスをレンダーしています。たとえば、`SearchBar` は以下のようにしてインプットの value を指定しています： ```js {1,6} function SearchBar({ filterText, inStockOnly }) { @@ -457,16 +457,16 @@ function SearchBar({ filterText, inStockOnly }) { placeholder="Search..."/> ``` -However, you haven't added any code to respond to the user actions like typing yet. This will be your final step. +ただし、まだユーザからのアクション（タイピングなど）に対応するコードを何も書いていません。これが最後のステップになります。 -## Step 5: Add inverse data flow {/*step-5-add-inverse-data-flow*/} +## ステップ 5：逆方向のデータフローを追加する {/*step-5-add-inverse-data-flow*/} -Currently your app renders correctly with props and state flowing down the hierarchy. But to change the state according to user input, you will need to support data flowing the other way: the form components deep in the hierarchy need to update the state in `FilterableProductTable`. +現在のところこのアプリでは、props と state が階層構造の下方向に向かって流れ、適切に表示が行われています。ただし、ユーザの入力に従って state を変更するには、逆方向へのデータの流れをサポートする必要があります。つまり、階層の深いところにあるフォームコンポーネントが、`FilterableProductTable` に存在する state を更新できる必要があるわけです。 -React makes this data flow explicit, but it requires a little more typing than two-way data binding. If you try to type or check the box in the example above, you'll see that React ignores your input. This is intentional. By writing ``, you've set the `value` prop of the `input` to always be equal to the `filterText` state passed in from `FilterableProductTable`. Since `filterText` state is never set, the input never changes. +双方向データバインディングより多少タイプ量は増えますが、React ではこのデータフローを明示的に記述します。上記の例で何かタイプするか、チェックボックスをオンにしようとしても、React が入力を無視するのがわかるでしょう。これは意図的なものです。`` と記述することで、 `input` の props である `value` を、`FilterableProductTable` から渡された state である `filterText` と常に等しくせよ、という意味になります。 `filterText` の state はまだ一切セットされていないため、入力値が変わることもありません。 -You want to make it so whenever the user changes the form inputs, the state updates to reflect those changes. The state is owned by `FilterableProductTable`, so only it can call `setFilterText` and `setInStockOnly`. To let `SearchBar` update the `FilterableProductTable`'s state, you need to pass these functions down to `SearchBar`: +ユーザがフォームの内容を変更するたびに、state がそれらの変更を反映して更新されるようにしたいと思います。state は `FilterableProductTable` によって所有されているため、このコンポーネントのみが `setFilterText` と `setInStockOnly` を呼び出すことができます。`SearchBar` が `FilterableProductTable` の state を更新できるようにするには、これらの関数を `SearchBar` に渡す必要があります。 ```js {2,3,10,11} function FilterableProductTable({ products }) { @@ -482,7 +482,7 @@ function FilterableProductTable({ products }) { onInStockOnlyChange={setInStockOnly} /> ``` -Inside the `SearchBar`, you will add the `onChange` event handlers and set the parent state from them: +`SearchBar` の中で `onChange` イベントハンドラを追加し、それらから親 state を設定します。 ```js {5} onFilterTextChange(e.target.value)} /> ``` -Now the application fully works! +これでアプリは完全に動作するようになりました！ @@ -642,8 +642,8 @@ td { -You can learn all about handling events and updating state in the [Adding Interactivity](/learn/adding-interactivity) section. +イベントの処理や state の更新に関しては、[インタラクティビティの追加](/learn/adding-interactivity)のセクションで学ぶことができます。 -## Where to go from here {/*where-to-go-from-here*/} +## 次に向かう場所 {/*where-to-go-from-here*/} -This was a very brief introduction to how to think about building components and applications with React. You can [start a React project](/learn/installation) right now or [dive deeper on all the syntax](/learn/describing-the-ui) used in this tutorial. +ここまでが、React を使ってコンポーネントやアプリケーションを構築する際の考え方についての、非常に簡単な紹介でした。今すぐ [React のプロジェクトを始める](/learn/installation)か、あるいは本チュートリアルで使用された[すべての構文について詳しく学ぶ](/learn/describing-the-ui)ことができます。 diff --git a/src/sidebarLearn.json b/src/sidebarLearn.json index f3d5e5dfe..6bacb4618 100644 --- a/src/sidebarLearn.json +++ b/src/sidebarLearn.json @@ -15,7 +15,7 @@ "path": "/learn/tutorial-tic-tac-toe" }, { - "title": "Thinking in React", + "title": "React の流儀", "path": "/learn/thinking-in-react" } ]