thinking in react（part2）

翻译

---

italicized 斜体

represents 代表

SearchBar 收缩栏

category 类别

turquoise 绿松石（一种颜色）

rendering 渲染

affordances 启示

certainly 肯定的

make sense to 有道理

identified 确定

arrange 安排

hierarchy 层次结构

You'll see here that we have five components in our simple app. I've italicized the data each component represents.

你可以清楚的看见，我们的简单功能的app里有5个组件。我把每个组件的代表都斜体化。

FilterableProductTable (orange): contains the entirety of the example

FilterableProductTable (orange):包裹了整个简单的收索栏，接收所有的用户输入

ProductTable (green): displays and filters the data collection based on user input

ProductTable (green):通过在用户输入的基础上进行数据的过滤和展示。

receives all user input

SearchBar (blue):接收所有的用户输入

ProductCategoryRow (turquoise): displays a heading for each category

ProductCategoryRow (turquoise):为每个类别展现一个头部

displays a row for each product

ProductRow (red):每个产品展示一行

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, I 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.

然而，如果这个头部变得复杂，（如果我们想为了排序增加启示），这使得去构建他自己的产品表单头部组建是肯定有道理的。

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:

现在我们可以区分我们模型里的组件，让我们安排这些组件到相应的层次结构中。这是很简单的，在模型中，组件和组件一起出现可以使一个组件以子模型的方式出现。