From 22833e181c1703586d360ad47361c1bb3c7472fb Mon Sep 17 00:00:00 2001 From: QC-L Date: Thu, 9 May 2019 14:52:47 +0800 Subject: [PATCH] translate comments --- content/docs/higher-order-components.md | 43 ++++++++++++------------- 1 file changed, 21 insertions(+), 22 deletions(-) diff --git a/content/docs/higher-order-components.md b/content/docs/higher-order-components.md index f8a4c2c29f..a42770cc44 100644 --- a/content/docs/higher-order-components.md +++ b/content/docs/higher-order-components.md @@ -4,7 +4,7 @@ title: 高阶组件 permalink: docs/higher-order-components.html --- -高阶组件（HOC）是 React 中用于复用组件逻辑的一种高级技巧。HOC 自身不是 React API 的一部分，它是一种基于 React 的组合特性形成的设计模式。 +高阶组件（HOC）是 React 中用于复用组件逻辑的一种高级技巧。HOC 自身不是 React API 的一部分，它是一种基于 React 的组合特性而形成的设计模式。 具体而言，**高阶组件是参数为组件，返回值为新组件的函数。** @@ -18,15 +18,15 @@ HOC 在 React 的第三方库中很常见，例如 Redux 的 [`connect`](https:/ 在本文档中，我们将讨论为什么高阶组件有用，以及如何编写自己的 HOC 函数。 -## 使用 HOC 处理横切关注点 {#use-hocs-for-crossing-cutting-concerns} +## 使用 HOC 解决横切关注点问题 {#use-hocs-for-crossing-cutting-concerns} > **注意** > -> 我们之前建议使用 mixins 用于处理横切关注点相关的问题。但我们已经意识到 mixins 会产生更多麻烦。[阅读更多](/blog/2016/07/13/mixins-consideration-hazardous.html) 关于我们为什么要抛弃 mixins 以及如何转换现有组件。 +> 我们之前建议使用 mixins 用于解决横切关注点相关的问题。但我们已经意识到 mixins 会产生更多麻烦。[阅读更多](/blog/2016/07/13/mixins-consideration-hazardous.html) 关于我们为什么要抛弃 mixins 以及如何转换现有组件。 组件是 React 中代码复用的基本单元。但你会发现某些模式并不适合传统组件。 -例如，假设有一个 `CommentList` 组件，它订阅外部数据源以渲染评论列表： +例如，假设有一个 `CommentList` 组件，它订阅外部数据源，用以渲染评论列表： ```js class CommentList extends React.Component { @@ -68,7 +68,7 @@ class CommentList extends React.Component { } ``` -稍后，你编写了一个用于订阅单个博客帖子的组件，该帖子遵循类似的模式： +稍后，编写了一个用于订阅单个博客帖子的组件，该帖子遵循类似的模式： ```js class BlogPost extends React.Component { @@ -100,15 +100,15 @@ class BlogPost extends React.Component { } ``` -`CommentList` 和 `BlogPost` 不同 - 它们在 `DataSource` 上调用不同的方法，并渲染不同的结果。但它们的大部分实现都是一样的： +`CommentList` 和 `BlogPost` 不同 - 它们在 `DataSource` 上调用不同的方法，且渲染不同的结果。但它们的大部分实现都是一样的： -- 在 mount 时，向 `DataSource` 添加一个更改侦听器。 +- 在挂载时，向 `DataSource` 添加一个更改侦听器。 - 在侦听器内部，当数据源发生变化时，调用 `setState`。 -- 在 unmount 时，删除侦听器。 +- 在卸载时，删除侦听器。 你可以想象，在一个大型应用程序中，这种订阅 `DataSource` 和调用 `setState` 的模式将一次又一次地发生。我们需要一个抽象，允许我们在一个地方定义这个逻辑，并在许多组件之间共享它。这正是高阶组件擅长的地方。 -我们可以编写一个创建组件的函数，比如 `CommentList` 和 `BlogPost`，订阅 `DataSource`。该函数将接受一个子组件作为其参数之一，该子组件将订阅数据作为 prop。让我们调用函数 `withSubscription`： +我们可以编写一个创建组件的函数，比如 `CommentList` 和 `BlogPost`，订阅 `DataSource`。该函数将接受一个子组件作为它的其中一个参数，该子组件将订阅数据作为 prop。让我们调用函数 `withSubscription`： ```js const CommentListWithSubscription = withSubscription( @@ -122,7 +122,7 @@ const BlogPostWithSubscription = withSubscription( ); ``` -第一个参数是被包装组件。第二个参数通过 `DataSource` 和当前的 props 返回我们感兴趣的数据。 +第一个参数是被包装组件。第二个参数通过 `DataSource` 和当前的 props 返回我们需要的数据。 当渲染 `CommentListWithSubscription` 和 `BlogPostWithSubscription` 时， `CommentList` 和 `BlogPost` 将传递一个 `data` prop，其中包含从 `DataSource` 检索到的最新数据： @@ -165,7 +165,7 @@ function withSubscription(WrappedComponent, selectData) { 请注意，HOC 不会修改传入的组件，也不会使用继承来复制其行为。相反，HOC 通过将组件*包装*在容器组件中来*组成*新组件。HOC 是纯函数，没有副作用。 -就是这样！被包装组件接收来自容器组件的所有 prop，同时也接收一个新的用于 render 的 `data` prop。 HOC 不需要关心数据的使用方式或原因，而被包装组件也不需要关心数据是怎么来的。 +被包装组件接收来自容器组件的所有 prop，同时也接收一个新的用于 render 的 `data` prop。HOC 不需要关心数据的使用方式或原因，而被包装组件也不需要关心数据是怎么来的。 因为 `withSubscription` 是一个普通函数，你可以根据需要对参数进行增添或者删除。例如，您可能希望使 `data` prop 的名称可配置，以进一步将 HOC 与包装组件隔离开来。或者你可以接受一个配置 `shouldComponentUpdate` 的参数，或者一个配置数据源的参数。因为 HOC 可以控制组件的定义方式，这一切都变得有可能。 @@ -191,9 +191,9 @@ const EnhancedComponent = logProps(InputComponent); 这样做会产生一些不良后果。其一是输入组件再也无法像 HOC 增强之前那样使用了。更严重的是，如果你再用另一个同样会修改 `componentWillReceiveProps` 的 HOC 增强它，那么前面的 HOC 就会失效！同时，这个 HOC 也无法应用于没有生命周期的函数组件。 -HOC 不应修改传入的组件，那是一种糟糕的抽象方式。消费者必须知道他们是如何实现的，以避免与其他 HOC 发生冲突。 +修改传入组件的 HOC 是一种糟糕的抽象方式。调用者必须知道他们是如何实现的，以避免与其他 HOC 发生冲突。 -HOC 不应该修改传入组件，而应该使用组合，通过将组件包装在容器组件中实现功能： +HOC 不应该修改传入组件，而应该使用组合的方式，通过将组件包装在容器组件中实现功能： ```js function logProps(WrappedComponent) { @@ -203,16 +203,16 @@ function logProps(WrappedComponent) { console.log('Next props: ', nextProps); } render() { - // Wraps the input component in a container, without mutating it. Good! + // 将 input 组件包装在容器中，而不对其进行修改。Good! return ; } } } ``` -该 HOC 和上文中修改传入组件的 HOC 功能相同，同时避免了冲突的可能性。它同样适用于 class 组件和函数组件。而且因为它是一个纯函数，它可以与其他 HOC 组合，甚至可以与其自身组合。 +该 HOC 与上文中修改传入组件的 HOC 功能相同，同时避免了出现冲突的情况。它同样适用于 class 组件和函数组件。而且因为它是一个纯函数，它可以与其他 HOC 组合，甚至可以与其自身组合。 -您可能已经注意到 HOC 与称为**容器组件模式**之间有相似之处。容器组件分离将高层和低层关注的责任，由容器管理订阅和状态，并将 prop 传递给处理渲染 UI。 HOC 使用容器作为其实现的一部分，你可以将 HOC 视为参数化容器组件。 +您可能已经注意到 HOC 与**容器组件模式**之间有相似之处。容器组件担任分离将高层和低层关注的责任，由容器管理订阅和状态，并将 prop 传递给处理渲染 UI。HOC 使用容器作为其实现的一部分，你可以将 HOC 视为参数化容器组件。 ## 约定：将不相关的 props 传递给被包裹的组件 {#convention-pass-unrelated-props-through-to-wrapped-component} @@ -222,15 +222,14 @@ HOC 应该透传与自身无关的 props。大多数 HOC 都应该包含一个 ```js render() { - // Filter out extra props that are specific to this HOC and shouldn't be - // passed through + // 过滤掉非此 HOC 额外的 props，且不要进行透传 const { extraProp, ...passThroughProps } = this.props; - // Inject props into the wrapped component. These are usually state values or - // instance methods. + // 将 props 注入到被包装的组件中。 + // 通常为 state 的值或者实例方法。 const injectedProp = someStateOrInstanceMethod; - // Pass props to wrapped component + // 将 props 传递给被包装组件 return (