React - Mixins 是“有害”的（Mixins Considered Harmful）

[tcatche]

本文博客地址：React - Mixins 是“有害”的（Mixins Considered Harmful）.

原文：Mixins Considered Harmful

“How do I share the code between several components?” is one of the first questions that people ask when they learn React. Our answer has always been to use component composition for code reuse. You can define a component and use it in several other components.

“我如何在几个组件之间共享代码？”，这是人们在学习 React 时提出的一个问题。我们的答案一直是使用组件组合来进行代码重用。你可以定义一个组件并在其他几个组件中使用它。

It is not always obvious how a certain pattern can be solved with composition. React is influenced by functional programming but it came into the field that was dominated by object-oriented libraries. It was hard for engineers both inside and outside of Facebook to give up on the patterns they were used to.

通过组合解决特定模式并不总是很明显。React 受函数式编程影响，但它进入了面向对象库主导的领域。 Facebook 内部和其他外面的工程师很难放弃他们习惯的模式。

To ease the initial adoption and learning, we included certain escape hatches into React. The mixin system was one of those escape hatches, and its goal was to give you a way to reuse code between components when you aren’t sure how to solve the same problem with composition.

为了更容易最初的适应和学习 React，我们在 React 中包含了一些逃生舱口。mixin 系统是其中之一，它的目标是为你提供一种在组件之间重用代码的方法，当你不确定如何使用组合解决相同的问题时。

Three years passed since React was released. The landscape has changed. Multiple view libraries now adopt a component model similar to React. Using composition over inheritance to build declarative user interfaces is no longer a novelty. We are also more confident in the React component model, and we have seen many creative uses of it both internally and in the community.

React 发布三年了，环境已经改变了。现在多个视图库采用类似于 React 的组件模型。使用组合而不是继承来构建声明式用户界面不再是新奇的事物。我们对 React 的组件模型也更有信心，而且我们在内部和社区都看到了很多创造性的用途。

In this post, we will consider the problems commonly caused by mixins. Then we will suggest several alternative patterns for the same use cases. We have found those patterns to scale better with the complexity of the codebase than mixins.

在这篇文章中，我们将思考由 mixins 引起的问题。并且我们将为相同的用例提出几种 mixins 的替代模式。我们发现这些模式与 mixins 相比较，更适应复杂的代码库。

Why Mixins are Broken

At Facebook, React usage has grown from a few components to thousands of them. This gives us a window into how people use React. Thanks to declarative rendering and top-down data flow, many teams were able to fix a bunch of bugs while shipping new features as they adopted React.

在 Facebook，React 的使用已经从几个组件增长到数千个。这给了我们一个人们如何使用 React 的窗口。由于声明式渲染和自上而下的数据流，许多团队采用React 能够修复一大堆错误，同时发布新功能。

However it’s inevitable that some of our code using React gradually became incomprehensible. Occasionally, the React team would see groups of components in different projects that people were afraid to touch. These components were too easy to break accidentally, were confusing to new developers, and eventually became just as confusing to the people who wrote them in the first place. Much of this confusion was caused by mixins. At the time, I wasn’t working at Facebook but I came to the same conclusions after writing my fair share of terrible mixins.

然而，不可避免的，我们使用 React 的一些代码逐渐变得难以理解。有时候，React 小组在不同的项目中能看到很多人们害怕接触的组件。这些组件太容易被意外地破坏，使新的开发人员感到困惑，最终变得即使最初编写它们的人也一样困惑。很多这样的混乱是由 mixins 造成的。虽然当时我没有在 Facebook 上工作，但是在写出我的关于 mixins 的糟糕之处的分享后，我得出了同样的结论。

This doesn’t mean that mixins themselves are bad. People successfully employ them in different languages and paradigms, including some functional languages. At Facebook, we extensively use traits in Hack which are fairly similar to mixins. Nevertheless, we think that mixins are unnecessary and problematic in React codebases. Here’s why.

这并不意味着 mixins 本身是坏的。人们成功地在不同的语言和范例中使用它，包括一些函数式语言。在 Facebook，我们广泛地在 Hack 语言中使用 traits，它们与 mixins 非常相似。尽管如此，我们仍然认为在 React 代码库中，mixins 是不必要的和容易出问题的。这里列出来为什么这样说的几条理由：

Mixins 引入了隐式的依赖关系（Mixins introduce implicit dependencies）

Sometimes a component relies on a certain method defined in the mixin, such as getClassName(). Sometimes it’s the other way around, and mixin calls a method like renderHeader() on the component. JavaScript is a dynamic language so it’s hard to enforce or document these dependencies.

有时一个组件依赖于在 mixin 中定义的某个确定方法，例如 getClassName()。有时相反，mixin 在组件上调用 renderHeader() 方法。 JavaScript 是一种动态语言，因此很难强制记录这些依赖关系。

Mixins break the common and usually safe assumption that you can rename a state key or a method by searching for its occurrences in the component file. You might write a stateful component and then your coworker might add a mixin that reads this state. In a few months, you might want to move that state up to the parent component so it can be shared with a sibling. Will you remember to update the mixin to read a prop instead? What if, by now, other components also use this mixin?

Mixins 打破了常见的，通常是安全的假设，你可以通过搜索 state 在组件文件中的出现位置来重命名它的键名或方法。你可能会写一个有状态的组件，然后你的同事可能添加一个读取这个组件 state 的 mixin。几个月之后，你可能希望将该 state 移动到父组件，以便与其兄弟组件共享。你会记得更新这个 mixin 来读取 props 而不是 state 吗？如果此时，其他组件也在使用这个 mixin 呢？

These implicit dependencies make it hard for new team members to contribute to a codebase. A component’s render() method might reference some method that isn’t defined on the class. Is it safe to remove? Perhaps it’s defined in one of the mixins. But which one of them? You need to scroll up to the mixin list, open each of those files, and look for this method. Worse, mixins can specify their own mixins, so the search can be deep.

这些隐含的依赖关系使得新的团队成员很难为代码库做出贡献。组件的 render() 方法可能引用一些未在该类上定义的方法，是否可以安全地删除？也许它是在一个 maxin 中定义的。但是是哪一个呢？你需要向上滚动到 mixin 列表，打开这些文件，并查找此方法。更糟糕的是，mixins 可以指定自己的 mixins，所以搜索层级可能会很深。

Often, mixins come to depend on other mixins, and removing one of them breaks the other. In these situations it is very tricky to tell how the data flows in and out of mixins, and what their dependency graph looks like. Unlike components, mixins don’t form a hierarchy: they are flattened and operate in the same namespace.

通常来说，mixins 依赖于其他 mixin，并且删除其中的一个会破坏另一个 mixin。在这些情况下，告诉数据如何流入和流出 mixin 以及它们的依赖图怎样是非常棘手的。与组件不同，mixins 不构成层次结构：它们被平坦化并在相同的命名空间中运行。

Mixins 引起名称冲突（Mixins cause name clashes）

There is no guarantee that two particular mixins can be used together. For example, if FluxListenerMixin defines handleChange() and WindowSizeMixin defines handleChange(), you can’t use them together. You also can’t define a method with this name on your own component.

无法保证两个特定的 mixin 可以一起使用。例如，如果 FluxListenerMixin 和 WindowSizeMixin 都定义了 handleChange()，则不能一起使用它们。同时，你也无法在自己的组件上定义具有此名称的方法。

It’s not a big deal if you control the mixin code. When you have a conflict, you can rename that method on one of the mixins. However it’s tricky because some components or other mixins may already be calling this method directly, and you need to find and fix those calls as well.

如果你控制此 mixin 代码，这倒还好，当有冲突时，你可以在其中一个mixins上重命名该方法。但是这也会很棘手，因为某些组件或其他 mixins 可能已经直接调用此方法，你还需要查找和修复这些调用。

If you have a name conflict with a mixin from a third party package, you can’t just rename a method on it. Instead, you have to use awkward method names on your component to avoid clashes.

如果你有与第三方软件包的 mixins 名称冲突，则无法重命名其上的方法。相反，你必须在组件上使用尴尬的方法名称才能避免冲突。

The situation is no better for mixin authors. Even adding a new method to a mixin is always a potentially breaking change because a method with the same name might already exist on some of the components using it, either directly or through another mixin. Once written, mixins are hard to remove or change. Bad ideas don’t get refactored away because refactoring is too risky.

对于 mixin 作者，情况也并不好。即使添加一个新的方法到 mixin 中也通常是一个潜在的破坏性的变化，因为具有相同的名称方法可能已经存在于使用它的一些组件，直接或通过另一个mixin。一旦写入，mixins 很难删除或改变。坏的设计也不会被重构，因为重构太危险了。

Mixins 导致滚雪球式的复杂性（Mixins cause snowballing complexity）

Even when mixins start out simple, they tend to become complex over time. The example below is based on a real scenario I’ve seen play out in a codebase.

即使刚开始的时候 mixins 很简单，它们往往随着时间的推移变得复杂。下面的例子是基于我在代码库中看到的一个真实场景。

A component needs some state to track mouse hover. To keep this logic reusable, you might extract handleMouseEnter(), handleMouseLeave() and isHovering() into a HoverMixin. Next, somebody needs to implement a tooltip. They don’t want to duplicate the logic in HoverMixin so they create a TooltipMixin that uses HoverMixin. TooltipMixin reads isHovering() provided by HoverMixin in its componentDidUpdate() and either shows or hides the tooltip.

一个组件需要一些状态来跟踪鼠标悬停。为了使逻辑可重用，你可以将 handleMouseEnter()、handleMouseLeave() 和 isHovering()提取到HoverMixin 中。接下来，有人需要实现一个工具提示。他们不想复制 HoverMixin 的逻辑，所以他们创建一个使用 HoverMixin 的 TooltipMixin。 TooltipMixin 在其 componentDidUpdate() 读取 HoverMixin 提供的 isHovering()，并显示或隐藏工具提示。

A few months later, somebody wants to make the tooltip direction configurable. In an effort to avoid code duplication, they add support for a new optional method called getTooltipOptions() to TooltipMixin. By this time, components that show popovers also use HoverMixin. However popovers need a different hover delay. To solve this, somebody adds support for an optional getHoverOptions() method and implements it in TooltipMixin. Those mixins are now tightly coupled.

几个月后，有人想让工具提示方向可配置。为了避免代码重复，他们对 TooltipMixin 增加了一个新的可选方法 getTooltipOptions() 的支持。到这个时候，另一个显示弹出层悬停的组件也使用 HoverMixin。然而，此组件需要不同的悬停延迟。为了解决这个问题，有人增加了对可选的 getTooltipOptions() 方法的支持，并在 TooltipMixin 中实现它。这些 mixins 现在紧密耦合。

This is fine while there are no new requirements. However this solution doesn’t scale well. What if you want to support displaying multiple tooltips in a single component? You can’t define the same mixin twice in a component. What if the tooltips need to be displayed automatically in a guided tour instead of on hover? Good luck decoupling TooltipMixin from HoverMixin. What if you need to support the case where the hover area and the tooltip anchor are located in different components? You can’t easily hoist the state used by mixin up into the parent component. Unlike components, mixins don’t lend themselves naturally to such changes.

这还好没有任何新的需求。然而，这个解决方案不能很好地扩展，如果你想支持在单个组件中显示多个工具提示怎么办？你不能在组件中定义相同的 mixin 两次。如果工具提示需要在引导中自动显示，而不是悬停展示？祝你从 HoverMixin 的解耦 TooltipMixin 好运。如果你需要支持悬停区域和工具提示锚位于不同组件的情况，该怎么办？你不能轻易地将 mixins 使用的状态提升到父组件中。与组件不同，mixins 并不适用于这些更改。

Every new requirement makes the mixins harder to understand. Components using the same mixin become increasingly coupled with time. Any new capability gets added to all of the components using that mixin. There is no way to split a “simpler” part of the mixin without either duplicating the code or introducing more dependencies and indirection between mixins. Gradually, the encapsulation boundaries erode, and since it’s hard to change or remove the existing mixins, they keep getting more abstract until nobody understands how they work.

每一个新的要求使得 mixins 更难理解。使用相同 mixin 的组件随时间变得越来越多。任何 mixin 的新的功能被添加到使用该 mixin 的所有组件。没有办法拆分mixin 的“更简单”的部分，而不需要复制代码或在 mixins 之间引入更多的依赖性和间接性。逐渐地，封装的边界被侵蚀，由于很难改变或删除现有的 mixins，它们不断变得更抽象，直到没有人了解它们如何工作。

These are the same problems we faced building apps before React. We found that they are solved by declarative rendering, top-down data flow, and encapsulated components. At Facebook, we have been migrating our code to use alternative patterns to mixins, and we are generally happy with the results. You can read about those patterns below.

这些是我们在 React 之前构建应用程序所遇到的同样的问题。我们发现它们通过声明性渲染，自上而下的数据流和封装的组件来解决。在 Facebook，我们一直在使用替代模式从 mixins 迁移我们的代码，通常，对迁移的结果都很满意。你可以阅读下面的这些模式。

从 Mixins 迁移（Migrating from Mixins）

Let’s make it clear that mixins are not technically deprecated. If you use React.createClass(), you may keep using them. We only say that they didn’t work well for us, and so we won’t recommend using them in the future.

让我们清楚的是，mixins 在技术上不被淘汰。如果你使用 React.createClass()，可以继续使用它们。我们只是说它对我们没有好处，所以我们不建议使用它们。

Every section below corresponds to a mixin usage pattern that we found in the Facebook codebase. For each of them, we describe the problem and a solution that we think works better than mixins. The examples are written in ES5 but once you don’t need mixins, you can switch to ES6 classes if you’d like.

下面的每个部分对应于我们在 Facebook 代码库中找到的 mixin 使用模式。对于它们中的每个，我们描述它们问题和我们认为比 mixins 更好的解决方案。这些例子是在ES5中编写的，但是一旦你不需要 mixin，你可以根据需要切换到 ES6 的类语法。

We hope that you find this list helpful. Please let us know if we missed important use cases so we can either amend the list or be proven wrong!

我们希望你发现此列表有帮助。如果我们错过重要的用例，请让我们知道，我们可以修改列表或修正错误！

性能优化（Performance Optimizations）

One of the most commonly used mixins is PureRenderMixin. You might be using it in some components to prevent unnecessary re-renders when the props and state are shallowly equal to the previous props and state:

最常用的 mixins 之一是 PureRenderMixin。当 props 和 state 和之前 props 和 state 浅相等时，你可能会在某些组件中使用它来防止不必要的重新渲染

var PureRenderMixin = require('react-addons-pure-render-mixin');

var Button = React.createClass({
  mixins: [PureRenderMixin],

  // ...

});

解决方案

To express the same without mixins, you can use the shallowCompare function directly instead:

不使用 mioxins 要实现相同的功能，你可以直接使用 shallowCompare 替代：

var shallowCompare = require('react-addons-shallow-compare');

var Button = React.createClass({
  shouldComponentUpdate: function(nextProps, nextState) {
    return shallowCompare(this, nextProps, nextState);
  },

  // ...

});

If you use a custom mixin implementing a shouldComponentUpdate function with different algorithm, we suggest exporting just that single function from a module and calling it directly from your components.

如果你使用自定义 mixin 来实现具有不同算法的 shouldComponentUpdate 函数，我们建议从模块导出该函数，并直接从组件中调用它。

We understand that more typing can be annoying. For the most common case, we plan to introduce a new base class called React.PureComponent in the next minor release. It uses the same shallow comparison as PureRenderMixin does today.

我们知道更多的输入字符可能会令人烦恼。对于最常见的情况，我们计划在下一个次要版本中引入一个名为 React.PureComponent 的新基类。它使用与现在的 PureRenderMixin 相同的浅比较。（注：该基类在v15.3.0 版本已经被引入）

订阅和副作用（Subscriptions and Side Effects）

The second most common type of mixins that we encountered are mixins that subscribe a React component to a third-party data source. Whether this data source is a Flux Store, an Rx Observable, or something else, the pattern is very similar: the subscription is created in componentDidMount, destroyed in componentWillUnmount, and the change handler calls this.setState().

我们遇到的第二种最常见的混合类型是将 React 组件订阅到第三方数据源的 mixins 。无论此数据源是 Flux Store，Rx Observable 还是其他内容，这些模式非常相似：在 componentDidMount 中创建订阅，在 componentWillUnmount 中销毁，调用 this.setState() 更改。

var SubscriptionMixin = {
  getInitialState: function() {
    return {
      comments: DataSource.getComments()
    };
  },

  componentDidMount: function() {
    DataSource.addChangeListener(this.handleChange);
  },

  componentWillUnmount: function() {
    DataSource.removeChangeListener(this.handleChange);
  },

  handleChange: function() {
    this.setState({
      comments: DataSource.getComments()
    });
  }
};

var CommentList = React.createClass({
  mixins: [SubscriptionMixin],

  render: function() {
    // Reading comments from state managed by mixin.
    var comments = this.state.comments;
    return (
      <div>
        {comments.map(function(comment) {
          return <Comment comment={comment} key={comment.id} />
        })}
      </div>
    )
  }
});

module.exports = CommentList;

解决方案

If there is just one component subscribed to this data source, it is fine to embed the subscription logic right into the component. Avoid premature abstractions.

如果只有一个组件订阅该数据源，将订阅逻辑嵌入到组件中是很好的。避免过早抽象。

If several components used this mixin to subscribe to a data source, a nice way to avoid repetition is to use a pattern called “higher-order components”. It can sound intimidating so we will take a closer look at how this pattern naturally emerges from the component model.

如果几个组件使用这个 mixin 来订阅数据源，避免重复的一个好方法是使用一个称为 高阶组件 的模式。它听起来很吓人，所以我们将仔细看看这个模式如何从组件模型中自然出现。

高阶组件说明(Higher-Order Components Explained)

Let’s forget about React for a second. Consider these two functions that add and multiply numbers, logging the results as they do that:

让我们暂时先忘记 React。考虑这两个函数，它们做加法和乘法，并打印日志记录结果：

function addAndLog(x, y) {
  var result = x + y;
  console.log('result:', result);
  return result;
}

function multiplyAndLog(x, y) {
  var result = x * y;
  console.log('result:', result);
  return result;
}

These two functions are not very useful but they help us demonstrate a pattern that we can later apply to components.

这两个功能并不是非常有用，但它们可以帮助我们展示给我们可以应用于组件的模式。

Let’s say that we want to extract the logging logic out of these functions without changing their signatures. How can we do this? An elegant solution is to write a higher-order function, that is, a function that takes a function as an argument and returns a function.

假设我们想从这些函数中提取记录逻辑，而不改变它们的签名。我们该怎么做呢？一个优雅的解决方案是写一个 高阶函数，即一个将一个函数作为一个参数并返回一个函数的高级函数。

Again, it sounds more intimidating than it really is:

这次，听起来更吓人：

function withLogging(wrappedFunction) {
  // Return a function with the same API...
  return function(x, y) {
    // ... that calls the original function
    var result = wrappedFunction(x, y);
    // ... but also logs its result!
    console.log('result:', result);
    return result;
  };
}

The withLogging higher-order function lets us write add and multiply without the logging statements, and later wrap them to get addAndLog and multiplyAndLog with exactly the same signatures as before:

withLogging 高阶函数可以让我们在没有日志记录语句的情况下编写加法和乘法，然后将它们打包成与以前完全相同的签名来获取 addAndLog 和 multiplyAndLog：

function add(x, y) {
  return x + y;
}

function multiply(x, y) {
  return x * y;
}

function withLogging(wrappedFunction) {
  return function(x, y) {
    var result = wrappedFunction(x, y);
    console.log('result:', result);
    return result;
  };
}

// Equivalent to writing addAndLog by hand:
// 等价于之前手写的 addAndLog 函数
var addAndLog = withLogging(add);

// Equivalent to writing multiplyAndLog by hand:
// 等价于之前手写的 multiplyAndLog 函数
var multiplyAndLog = withLogging(multiply);

Higher-order components are a very similar pattern, but applied to components in React. We will apply this transformation from mixins in two steps.

高阶组件是非常相似的模式，但是应用于 React 中的组件。我们将从两个步骤中从 mixins 中应用这个转换。

As a first step, we will split our CommentList component in two, a child and a parent. The child will be only concerned with rendering the comments. The parent will set up the subscription and pass the up-to-date data to the child via props.

第一步，我们将把我们的 CommentList 组件分成两部分，一个子组件和一个父组件。子组件只会关注渲染评论。父母将设置订阅，并通过 props 将最新数据传递给子组件。

// This is a child component.
// It only renders the comments it receives as props.
var CommentList = React.createClass({
  render: function() {
    // Note: now reading from props rather than state.
    var comments = this.props.comments;
    return (
      <div>
        {comments.map(function(comment) {
          return <Comment comment={comment} key={comment.id} />
        })}
      </div>
    )
  }
});

// This is a parent component.
// It subscribes to the data source and renders <CommentList />.
var CommentListWithSubscription = React.createClass({
  getInitialState: function() {
    return {
      comments: DataSource.getComments()
    };
  },

  componentDidMount: function() {
    DataSource.addChangeListener(this.handleChange);
  },

  componentWillUnmount: function() {
    DataSource.removeChangeListener(this.handleChange);
  },

  handleChange: function() {
    this.setState({
      comments: DataSource.getComments()
    });
  },

  render: function() {
    // We pass the current state as props to CommentList.
    return <CommentList comments={this.state.comments} />;
  }
});

module.exports = CommentListWithSubscription;

There is just one final step left to do.

只剩最后一步。

Remember how we made withLogging() take a function and return another function wrapping it? We can apply a similar pattern to React components.

还记得我们用 withLogging() 接收一个函数并返回一个包装它的函数吗？我们可以将类似的模式应用于 React 组件。

We will write a new function called withSubscription(WrappedComponent). Its argument could be any React component. We will pass CommentList as WrappedComponent, but we could also apply withSubscription() to any other component in our codebase.

我们将编写一个名为 withSubscription(WrappedComponent) 的新函数。它的参数可以是任何 React 组件。我们将传递 CommentList 作为WrappedComponent（被包装得组件），但是我们也可以将它们应用于我们的代码库中的任何其他组件。

This function would return another component. The returned component would manage the subscription and render <WrappedComponent /> with the current data.

此函数将返回另一个组件。返回的组件将管理订阅并使用当前数据渲染 <WrappedComponent />。

We call this pattern a “higher-order component”.

我们把这个模式叫做高阶组件。

The composition happens at React rendering level rather than with a direct function call. This is why it doesn’t matter whether the wrapped component is defined with createClass(), as an ES6 class or a function. If WrappedComponent is a React component, the component created by withSubscription() can render it.

组合发生在 React 渲染级别，而不是直接调用函数。这就是为什么被包装组件或者用 createClass() 定义的，或者 ES6 类或是函数式组件是毫无关系。如果 WrappedComponent 是一个 React 组件，则使用 withSubscription() 创建的组件都可以可以渲染它。

// This function takes a component...
function withSubscription(WrappedComponent) {
  // ...and returns another component...
  return React.createClass({
    getInitialState: function() {
      return {
        comments: DataSource.getComments()
      };
    },

    componentDidMount: function() {
      // ... that takes care of the subscription...
      DataSource.addChangeListener(this.handleChange);
    },

    componentWillUnmount: function() {
      DataSource.removeChangeListener(this.handleChange);
    },

    handleChange: function() {
      this.setState({
        comments: DataSource.getComments()
      });
    },

    render: function() {
      // ... and renders the wrapped component with the fresh data!
      return <WrappedComponent comments={this.state.comments} />;
    }
  });
}

Now we can declare CommentListWithSubscription by applying withSubscription to CommentList:

现在我们可以通过将 withSubscription 应用于 CommentList 来声明 CommentListWithSubscription：

var CommentList = React.createClass({
  render: function() {
    var comments = this.props.comments;
    return (
      <div>
        {comments.map(function(comment) {
          return <Comment comment={comment} key={comment.id} />
        })}
      </div>
    )
  }
});

// withSubscription() returns a new component that
// is subscribed to the data source and renders
// <CommentList /> with up-to-date data.
var CommentListWithSubscription = withSubscription(CommentList);

// The rest of the app is interested in the subscribed component
// so we export it instead of the original unwrapped CommentList.
module.exports = CommentListWithSubscription;

已解决，再次回顾一下（Solution, Revisited）

Now that we understand higher-order components better, let’s take another look at the complete solution that doesn’t involve mixins. There are a few minor changes that are annotated with inline comments:

现在我们更好地了解了高阶组件，让我们再来看一下不涉及 mixins 的完整解决方案。有一些小的更改用内联注释说明：

function withSubscription(WrappedComponent) {
  return React.createClass({
    getInitialState: function() {
      return {
        comments: DataSource.getComments()
      };
    },

    componentDidMount: function() {
      DataSource.addChangeListener(this.handleChange);
    },

    componentWillUnmount: function() {
      DataSource.removeChangeListener(this.handleChange);
    },

    handleChange: function() {
      this.setState({
        comments: DataSource.getComments()
      });
    },

    render: function() {
      // Use JSX spread syntax to pass all props and state down automatically.
      return <WrappedComponent {...this.props} {...this.state} />;
    }
  });
}

// Optional change: convert CommentList to a functional component
// because it doesn't use lifecycle hooks or state.
function CommentList(props) {
  var comments = props.comments;
  return (
    <div>
      {comments.map(function(comment) {
        return <Comment comment={comment} key={comment.id} />
      })}
    </div>
  )
}

// Instead of declaring CommentListWithSubscription,
// we export the wrapped component right away.
module.exports = withSubscription(CommentList);

Higher-order components are a powerful pattern. You can pass additional arguments to them if you want to further customize their behavior. After all, they are not even a feature of React. They are just functions that receive components and return components that wrap them.

高阶组件是一个强大的模式。如果你想进一步自定义它们的行为，你可以向它们传递其他参数。毕竟，他们甚至不是React的一个特征。它们只是接收组件并返回包装组件的函数。

Like any solution, higher-order components have their own pitfalls. For example, if you heavily use refs, you might notice that wrapping something into a higher-order component changes the ref to point to the wrapping component. In practice we discourage using refs for component communication so we don’t think it’s a big issue. In the future, we might consider adding ref forwarding to React to solve this annoyance.

像任何解决方案一样，高阶组件都有自己的缺陷。例如，如果你大量使用 refs（推荐本人另一篇文章：React - Refs），你可能会注意到，将某些内容包装到更高阶的组件中会将 ref 更改为指向包装组件。实际上，我们不鼓励使用 ref 进行组件通信，所以我们不认为这是一个大问题。在将来，我们可能会考虑添加ref 转发 到 React 来解决这个烦恼。

渲染逻辑(Rendering Logic)

The next most common use case for mixins that we discovered in our codebase is sharing rendering logic between components.

我们在代码库中发现的 mixins 的另一个最常见的用例是在组件之间共享渲染逻辑。

Here is a typical example of this pattern:

以下是此模式的典型示例：

var RowMixin = {
  // Called by components from render()
  renderHeader: function() {
    return (
      <div className='row-header'>
        <h1>
          {this.getHeaderText() /* Defined by components */}
        </h1>
      </div>
    );
  }
};

var UserRow = React.createClass({
  mixins: [RowMixin],

  // Called by RowMixin.renderHeader()
  getHeaderText: function() {
    return this.props.user.fullName;
  },

  render: function() {
    return (
      <div>
        {this.renderHeader() /* Defined by RowMixin */}
        <h2>{this.props.user.biography}</h2>
      </div>
    )
  }
});

Multiple components may be sharing RowMixin to render the header, and each of them would need to define getHeaderText().

多个组件可能共享 RowMixin 来渲染头部，并且每个组件都需要定义 getHeaderText()。

解决方案

If you see rendering logic inside a mixin, it’s time to extract a component!

如果你在 mixin 中看到渲染逻辑，现在是时候提取组件了！

Instead of RowMixin, we will define a <RowHeader> component. We will also replace the convention of defining a getHeaderText() method with the standard mechanism of top-data flow in React: passing props.

与使用 RowMixin 相比，我们将定义一个 <RowHeader> 组件。我们还将使用 React 中的顶级数据流（props）的标准机制来替换定义 getHeaderText() 方法。

Finally, since neither of those components currently need lifecycle hooks or state, we can declare them as simple functions:

最后，既然这些组件当前都不需要生命周期钩子或 state，我们可以将它们声明为简单的函数式组件：

function RowHeader(props) {
  return (
    <div className='row-header'>
      <h1>{props.text}</h1>
    </div>
  );
}

function UserRow(props) {
  return (
    <div>
      <RowHeader text={props.user.fullName} />
      <h2>{props.user.biography}</h2>
    </div>
  );
}

Props keep component dependencies explicit, easy to replace, and enforceable with tools like Flow and TypeScript.

Props使组件依赖性保持明确，易于替换，并可通过 Flow 和 TypeScript 等工具强制执行。

Note:
Defining components as functions is not required. There is also nothing wrong with using lifecycle hooks and state—they are first-class React features. We use functional components in this example because they are easier to read and we didn’t need those extra features, but classes would work just as fine.

注意：
定义组件为函数式组件并不是必须的。使用生命周期钩子和 state 也没有错，他们是一流的 React 功能。我们在这个例子中使用函数式组件，因为它们更容易阅读，并且我们不需要这些额外的功能，当然使用类组件也可以正常工作。

上下文（Context）

Another group of mixins we discovered were helpers for providing and consuming React context. Context is an experimental unstable feature, has certain issues, and will likely change its API in the future. We don’t recommend using it unless you’re confident there is no other way of solving your problem.

我们发现的另一组 mixin 是提供和消费 React context（推荐本人另一篇总结React - Context） 的帮助者。上下文是一个实验性的不稳定特征，具有一定的问题，并且将来可能会改变其 API。我们不建议使用它，除非你确信没有其他方法来解决你的问题。

Nevertheless, if you already use context today, you might have been hiding its usage with mixins like this:

然而，如果你已经使用了上下文，那么你可能已经用这样的 mixins 隐藏了它的使用：

var RouterMixin = {
  contextTypes: {
    router: React.PropTypes.object.isRequired
  },

  // The mixin provides a method so that components
  // don't have to use the context API directly.
  // mixin 提供了一个方法，确保组件不必直接操作 context 的 API
  push: function(path) {
    this.context.router.push(path)
  }
};

var Link = React.createClass({
  mixins: [RouterMixin],

  handleClick: function(e) {
    e.stopPropagation();

    // This method is defined in RouterMixin.
    this.push(this.props.to);
  },

  render: function() {
    return (
      <a onClick={this.handleClick}>
        {this.props.children}
      </a>
    );
  }
});

module.exports = Link;

解决方案

We agree that hiding context usage from consuming components is a good idea until the context API stabilizes. However, we recommend using higher-order components instead of mixins for this.

我们认同在 Context API 稳定之前，隐藏使用组件 Context API 是一个好主意。但是，我们建议使用更高阶的组件而不是 mixins。

Let the wrapping component grab something from the context, and pass it down with props to the wrapped component:

让包装组件从 context 中抓取东西，并使用 props 将其传递给被包装组件：

function withRouter(WrappedComponent) {
  return React.createClass({
    contextTypes: {
      router: React.PropTypes.object.isRequired
    },

    render: function() {
      // The wrapper component reads something from the context
      // and passes it down as a prop to the wrapped component.
      var router = this.context.router;
      return <WrappedComponent {...this.props} router={router} />;
    }
  });
};

var Link = React.createClass({
  handleClick: function(e) {
    e.stopPropagation();

    // The wrapped component uses props instead of context.
    this.props.router.push(this.props.to);
  },

  render: function() {
    return (
      <a onClick={this.handleClick}>
        {this.props.children}
      </a>
    );
  }
});

// Don't forget to wrap the component!
module.exports = withRouter(Link);

If you’re using a third party library that only provides a mixin, we encourage you to file an issue with them linking to this post so that they can provide a higher-order component instead. In the meantime, you can create a higher-order component around it yourself in exactly the same way.

如果你正在使用仅提供 mixin 的第三方库，我们建议你提交链接到此帖子的问题，以便他们可以提供更高级的组件。在此期间，你可以以完全相同的方式在其周围创建高阶组件。

功能方法(Utility Methods)

Sometimes, mixins are used solely to share utility functions between components:

有时，mixins 仅用于在组件之间共享功能函数：

var ColorMixin = {
  getLuminance(color) {
    var c = parseInt(color, 16);
    var r = (c & 0xFF0000) >> 16;
    var g = (c & 0x00FF00) >> 8;
    var b = (c & 0x0000FF);
    return (0.299 * r + 0.587 * g + 0.114 * b);
  }
};

var Button = React.createClass({
  mixins: [ColorMixin],

  render: function() {
    var theme = this.getLuminance(this.props.color) > 160 ? 'dark' : 'light';
    return (
      <div className={theme}>
        {this.props.children}
      </div>
    )
  }
});

解决方案

Put utility functions into regular JavaScript modules and import them. This also makes it easier to test them or use them outside of your components:

将功能程序函数放入常规的 JavaScript 模块并导入。这也使得更容易测试它们或在组件之外使用它们：

var getLuminance = require('../utils/getLuminance');

var Button = React.createClass({
  render: function() {
    var theme = getLuminance(this.props.color) > 160 ? 'dark' : 'light';
    return (
      <div className={theme}>
        {this.props.children}
      </div>
    )
  }
});

其他使用案例（Other Use Cases）

Sometimes people use mixins to selectively add logging to lifecycle hooks in some components. In the future, we intend to provide an official DevTools API that would let you implement something similar without touching the components. However it’s still very much a work in progress. If you heavily depend on logging mixins for debugging, you might want to keep using those mixins for a little longer.

有时，人们使用 mixins 来选择性地将日志记录添加到某些组件中的生命周期钩子中。在将来，我们打算提供一个官方的 official DevTools API，可以让你实现类似的操作，而不必触及组件。然而，这仍然是一项正在进行的工作。如果你严重依赖日志 mixins 来进行调试，那么你可能希望继续使用这些混合。

If you can’t accomplish something with a component, a higher-order component, or a utility module, it could be mean that React should provide this out of the box. File an issue to tell us about your use case for mixins, and we’ll help you consider alternatives or perhaps implement your feature request.

如果你无法使用组件，高阶组件或功能模块完成某些操作，则可能意味着 React 应提供额外的操作。在此提出问题，告诉我们你的关于 mixins 的用例，我们将帮助你考虑你的功能请求的替代方案，或者可能的实现方案。

Mixins are not deprecated in the traditional sense. You can keep using them with React.createClass(), as we won’t be changing it further. Eventually, as ES6 classes gain more adoption and their usability problems in React are solved, we might split React.createClass() into a separate package because most people wouldn’t need it. Even in that case, your old mixins would keep working.

Mixins 在传统场景下并不过期。你任然可以通过使用 React.createClass() 继续使用它们，因为我们不会进一步改变它们。最终，随着 ES6 类得到更多的采用，在 React 中的可用性问题得到解决，我们可能将 React.createClass() 分解成一个单独的包，因为大多数人不需要它。即使在这种情况下，你的旧的 mixins 也会继续工作。

We believe that the alternatives above are better for the vast majority of cases, and we invite you to try writing React apps without using mixins.

我们认为，在绝大多数情况下，上述替代方案更好，我们邀请你尝试在不使用 mixins 的情况下编写 React 应用程序。