Skip to content

Commit afd9450

Browse files
authored
fix: change the translation of mock. 原型图 ->设计稿 (reactjs#80)
* fix: change the translation of mock. 原型图 ->设计稿 * fix: build error
1 parent b890b65 commit afd9450

File tree

2 files changed

+5
-5
lines changed

2 files changed

+5
-5
lines changed

content/blog/2015-03-30-community-roundup-26.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,7 @@ Colin also [blogged about his experience using React Native](http://blog.scottlo
2929

3030
Spencer Ahrens and I had the great pleasure to talk about React Native on [The Changelog](https://thechangelog.com/149/) podcast. It was really fun to chat for an hour, I hope that you'll enjoy listening to it. :)
3131

32-
<audio src="http://fdlyr.co/d/changelog/cdn.5by5.tv/audio/broadcasts/changelog/2015/changelog-149.mp3" controls="controls" style="width: 100%"></audio>
32+
<audio src="https://fdlyr.co/d/changelog/cdn.5by5.tv/audio/broadcasts/changelog/2015/changelog-149.mp3" controls="controls" style="width: 100%"></audio>
3333

3434

3535
## Hacker News

content/docs/thinking-in-react.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -12,9 +12,9 @@ prev: composition-vs-inheritance.html
1212

1313
React 最棒的部分之一是引导我们思考如何构建一个应用。在这篇文档中,我们将会通过 React 构建一个可搜索的产品数据表格来更深刻地领会 React 哲学。
1414

15-
## 从原型图开始
15+
## 从设计稿开始
1616

17-
假设我们已经有了一个返回 JSON 的 API,以及设计师提供的组件原型图。如下所示:
17+
假设我们已经有了一个返回 JSON 的 API,以及设计师提供的组件设计稿。如下所示:
1818

1919
![Mockup](../images/blog/thinking-in-react-mock.png)
2020

@@ -33,7 +33,7 @@ React 最棒的部分之一是引导我们思考如何构建一个应用。在
3333

3434
## 第一步:将设计好的 UI 划分为组件层级
3535

36-
首先,你需要在原型图上用方框圈出每一个组件(包括它们的子组件),并且以合适的名称命名。如果你是和设计师一起完成此任务,那么他们可能已经做过类似的工作,所以请和他们进行交流!他们的 Photoshop 的图层名称可能最终就是你编写的 React 组件的名称!
36+
首先,你需要在设计稿上用方框圈出每一个组件(包括它们的子组件),并且以合适的名称命名。如果你是和设计师一起完成此任务,那么他们可能已经做过类似的工作,所以请和他们进行交流!他们的 Photoshop 的图层名称可能最终就是你编写的 React 组件的名称!
3737

3838
但你如何确定应该将哪些部分划分到一个组件中呢?你可以将组件当作一种函数或者是对象来考虑,根据[单一功能原则](https://en.wikipedia.org/wiki/Single_responsibility_principle)来判定组件的范围。也就是说,一个组件原则上只能负责一个功能。如果它需要负责更多的功能,这时候就应该考虑将它拆分成更小的组件。
3939

@@ -51,7 +51,7 @@ React 最棒的部分之一是引导我们思考如何构建一个应用。在
5151

5252
你可能注意到,`ProductTable` 的表头(包含 "Name" 和 "Price" 的那一部分)并未单独成为一个组件。这仅仅是一种偏好选择,如何处理这一问题也一直存在争论。就这个示例而言,因为表头只起到了渲染*数据集合*的作用——这与 `ProductTable` 是一致的,所以我们仍然将其保留为 `ProductTable` 的一部分。但是,如果表头过于复杂(比如我们需为其添加排序功能),那么将它作为一个独立的 `ProductTableHeader` 组件就显得很有必要了。
5353

54-
现在我们已经确定了原型图中应该包含的组件,接下来我们将把它们描述为更加清晰的层级。原型图中被其他组件包含的子组件,在层级上应该作为其子节点。
54+
现在我们已经确定了设计稿中应该包含的组件,接下来我们将把它们描述为更加清晰的层级。设计稿中被其他组件包含的子组件,在层级上应该作为其子节点。
5555

5656
* `FilterableProductTable`
5757
* `SearchBar`

0 commit comments

Comments
 (0)