From 23d9919b7888140cd29620fa2da862e9a8051f47 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E9=98=BF=E5=8D=A1=E7=90=B3?= Date: Tue, 8 May 2018 11:15:44 +0800 Subject: [PATCH] docs: remove invisible characters (#2) --- book/chapter-10/README.md | 4 ++-- book/chapter-2/README.md | 2 +- book/chapter-4/README.md | 2 +- book/chapter-8/README.md | 4 ++-- book/chapter-9/README.md | 6 +++--- 5 files changed, 9 insertions(+), 9 deletions(-) diff --git a/book/chapter-10/README.md b/book/chapter-10/README.md index 88787f2..7301351 100644 --- a/book/chapter-10/README.md +++ b/book/chapter-10/README.md @@ -2,7 +2,7 @@ 我们写的好多模块和组件都有依赖。能否管理这些依赖对于项目的成功至关重要。有一种叫做 [*依赖注入*](http://krasimirtsonev.com/blog/article/Dependency-injection-in-JavaScript) 的技术 (大多数人认为它是一种*模式*) 用来解决这种问题。 -在 React 中，对依赖注入的需要是显而易见的。我们来考虑下面的应用的组件树: +在 React 中，对依赖注入的需要是显而易见的。我们来考虑下面的应用的组件树: ```js // Title.jsx @@ -202,7 +202,7 @@ export default function wire(Component, dependencies, mapper) { ## 使用 React context (16.3 及之后的版本) -这些年来，Fackbook 并不推荐使用 context API 。在官方文档中也有提到，此 API 不稳定，随时可能更改。确实也言中了。16.3 版本提供了一个新的 context API ，我认为新版 API 更自然，使用起来也更简单。 +这些年来，Fackbook 并不推荐使用 context API 。在官方文档中也有提到，此 API 不稳定，随时可能更改。确实也言中了。16.3 版本提供了一个新的 context API ，我认为新版 API 更自然，使用起来也更简单。 我们还是使用同一个示例，让字符串抵达 `` 组件。 diff --git a/book/chapter-2/README.md b/book/chapter-2/README.md index b4cc136..7a32931 100644 --- a/book/chapter-2/README.md +++ b/book/chapter-2/README.md @@ -26,7 +26,7 @@ function App() { } ``` -`Title` 组件只有一个输入属性 `text` 。父组件 (`App`) 在使用 `<Title>` 标签时提供此属性。在定义组件的同时我们还定义了 `propTypes` 。在 `propTypes` 中我们定义了每个属性的类型，这样的话，当某些属性的类型并非我们所预期时，React 会在控制台中进行提示。`defaultProps` 是另一个有用的选项。我们可以使用它来为组件的属性设置默认值，这样就算开发者忘记传入属性也能保障组件具有有效值。 +`Title` 组件只有一个输入属性 `text` 。父组件 (`App`) 在使用 `<Title>` 标签时提供此属性。在定义组件的同时我们还定义了 `propTypes` 。在 `propTypes` 中我们定义了每个属性的类型，这样的话，当某些属性的类型并非我们所预期时，React 会在控制台中进行提示。`defaultProps` 是另一个有用的选项。我们可以使用它来为组件的属性设置默认值，这样就算开发者忘记传入属性也能保障组件具有有效值。 React 并没有严格定义传入的属性应该是什么。它可以是任何我们想要传入的。例如，它可以是另外一个组件: diff --git a/book/chapter-4/README.md b/book/chapter-4/README.md index d454954..872fb47 100644 --- a/book/chapter-4/README.md +++ b/book/chapter-4/README.md @@ -34,7 +34,7 @@ export default function Navigation() { 但是，这种方式会引入一些问题: * 我们可以把 `App` 看作是主要的组合场所。`Header` 可能还有其他元素，比如 logo、搜索框或标语。如果它们是以某种方式通过 `App` 组件传入的就好了，这样我们就无需创建目前这种硬编码的依赖关系。再比如说我们如果需要一个没有 `Navigation` 的 `Header` 组件该怎么办？我们无法轻松实现，因为我们将这两个组件紧绑在了一起。 -* 代码很难测试。在 `Header` 中或许有一些业务逻辑，要测试它的话我们需要创建出一个组件实例。但是，因为它还导入了其他组件，所以我们还要为这些导入的组件创建实例，这样的话测试就变的很重。如果 `Navigation` 组件出了问题，那么 `Header` 组件的测试已将被破坏，这完全不是我们想要的效果。*(注意: [浅层渲染 ( shallow rendering )](https://facebook.github.io/react/docs/test-utils.html#shallow-rendering) 通过不渲染 `Header` 组件嵌套的子元素能在一定程度上解决此问题。)* +* 代码很难测试。在 `Header` 中或许有一些业务逻辑，要测试它的话我们需要创建出一个组件实例。但是，因为它还导入了其他组件，所以我们还要为这些导入的组件创建实例，这样的话测试就变的很重。如果 `Navigation` 组件出了问题，那么 `Header` 组件的测试已将被破坏，这完全不是我们想要的效果。*(注意: [浅层渲染 ( shallow rendering )](https://facebook.github.io/react/docs/test-utils.html#shallow-rendering) 通过不渲染 `Header` 组件嵌套的子元素能在一定程度上解决此问题。)* ## 使用 React children API diff --git a/book/chapter-8/README.md b/book/chapter-8/README.md index 869a042..418241f 100644 --- a/book/chapter-8/README.md +++ b/book/chapter-8/README.md @@ -18,7 +18,7 @@ ### Dispatcher -大多数场景下，我们只需要一个单个的 dispatcher 。因为它扮演胶水的角色，用来粘合其他部分，所以有一个就够了。dispatcher 需要知道两样东西: 动作和 stores 。动作只是简单地转发给 stores，所以没必要保存它们。然而，stores 应该在 dispatcher 中进行追踪，这样才可以遍历它们: +大多数场景下，我们只需要一个单个的 dispatcher 。因为它扮演胶水的角色，用来粘合其他部分，所以有一个就够了。dispatcher 需要知道两样东西: 动作和 stores 。动作只是简单地转发给 stores，所以没必要保存它们。然而，stores 应该在 dispatcher 中进行追踪，这样才可以遍历它们: ![the dispatcher](./fluxiny_the_dispatcher.jpg) @@ -70,7 +70,7 @@ register: function (store) { Framework.attachToStore(view, store); ``` -然而，我并不怎么喜欢这种方式。要让 `attachToStore` 正常运行，需要视图和 store 中有一个特殊的 API ，因此我们需要严格定义这个新的公有方法。或者换句话说，Framework 对你说道: “你的视图和 store 应该具备这样的 API ，这样我才能能够将它们连接起来”。如果我们沿着这个方向前进的话，那么我们可能会定义可扩展的基类，这样我们就不会让 Flux 的细节去困扰开发人员。然后，Framework 又对你说到: “你所有的类都应该继承我们的类”。这听上去也并非好主意，因为开发人员可能会切换成另一个 Flux 提供者，这种切换势必会修改所有内容。 +然而，我并不怎么喜欢这种方式。要让 `attachToStore` 正常运行，需要视图和 store 中有一个特殊的 API ，因此我们需要严格定义这个新的公有方法。或者换句话说，Framework 对你说道: “你的视图和 store 应该具备这样的 API ，这样我才能能够将它们连接起来”。如果我们沿着这个方向前进的话，那么我们可能会定义可扩展的基类，这样我们就不会让 Flux 的细节去困扰开发人员。然后，Framework 又对你说到: “你所有的类都应该继承我们的类”。这听上去也并非好主意，因为开发人员可能会切换成另一个 Flux 提供者，这种切换势必会修改所有内容。 <br /><br /> diff --git a/book/chapter-9/README.md b/book/chapter-9/README.md index 9575db8..1d8fdcd 100644 --- a/book/chapter-9/README.md +++ b/book/chapter-9/README.md @@ -28,7 +28,7 @@ const action = { `visible` 属性是我们所提到过的元数据。它与 Redux 本身无关，它表示应用中某处需要使用的数据。 -每次我们想要派发动作时都需要使用这样的对象。但是，一遍又一遍地写确实是让太人烦躁了。这也正是概念 *action creators* 诞生的原因。action creator 是返回动作对象的函数，它可选项性地接收与动作相关联的属性。例如，如果将上面的 action 写成 action creator 会是这样: +每次我们想要派发动作时都需要使用这样的对象。但是，一遍又一遍地写确实是让太人烦躁了。这也正是概念 *action creators* 诞生的原因。action creator 是返回动作对象的函数，它可选项性地接收与动作相关联的属性。例如，如果将上面的 action 写成 action creator 会是这样: ```js const changeVisibility = visible => ({ @@ -159,7 +159,7 @@ const changeVisibility = visible => ({ ### Store 及其 reducers -我们在解释 store 和 reudcers 时，有些技术点是没有讨论到的。通常，我们会有多个 reducer ，因为要管理多种状态。store 只有一个，所以理论上只有一个状态对象。但是大多数生产环境的应用的状态都是状态切片的组合。每个切片代表应用的一部分。这个小示例拥有计数和可见性两个切片。所以我们的初始状态应该是这样的: +我们在解释 store 和 reudcers 时，有些技术点是没有讨论到的。通常，我们会有多个 reducer ，因为要管理多种状态。store 只有一个，所以理论上只有一个状态对象。但是大多数生产环境的应用的状态都是状态切片的组合。每个切片代表应用的一部分。这个小示例拥有计数和可见性两个切片。所以我们的初始状态应该是这样的: ```js const initialState = { @@ -312,4 +312,4 @@ Redux 是一种很棒的模式。最近几年，JavaScript 社区将这种理念 *顺便一提，我们还没有介绍过副作用管理。那将是另外的新篇章了，它有自己的理念和解决方案。* -我们可以得出结论，Redux 本身是一种非常简单的模式。它传授了非常有用的技术，但不幸的是光靠它自身往往是不够的。我们迟早要引入更多的概念或模式。当然这没有那么糟糕，我们只是先提起计划一下。 \ No newline at end of file +我们可以得出结论，Redux 本身是一种非常简单的模式。它传授了非常有用的技术，但不幸的是光靠它自身往往是不够的。我们迟早要引入更多的概念或模式。当然这没有那么糟糕，我们只是先提起计划一下。