react 组件中使用组件_禁止使用React功能组件的7个理由-CSDN博客

react 组件中使用组件

Are React’s Functional Components Worth The Cost?

React的功能组件值得吗？

Update 5/31/19: React 16.8 added Hooks, which mean you can use functional components for nearly everything! ? Function components are the future of React. So bottom-line, use functional components for future development. That said, the tradeoffs below apply for older codebases where Hooks aren’t an option. Happy coding!

19年5月31日更新 ：React 16.8添加了Hooks ，这意味着您几乎可以使用功能组件！？功能组件是React的未来。因此，最重要的是，将功能组件用于将来的开发。就是说，下面的折衷适用于不能使用Hooks的较旧代码库。编码愉快！

I’m spending the week consulting a team in Seattle to help accelerate their transition to React. Today, we discussed the 8 key decisions to make to standardize React development.

我花了一周的时间咨询西雅图的一个团队，以帮助他们加快向React的过渡。今天，我们讨论了使React开发标准化的8个关键决策。

I shared 9 reasons I’m a fan of functional components. One response surprised me:

我分享了我偏爱功能组件的9个理由。一个回应让我感到惊讶：

“Let’s forbid using functional components.”

“我们禁止使用功能组件。”

Woah, really? We discussed the issue at length. Here’s why.

哇，真的吗？我们详细讨论了这个问题。这就是为什么。

1.转换麻烦 (1. Conversion Hassle)

Functional components don’t support state, refs, or lifecycle methods. They can’t extend PureComponent either. Sometimes, you’ll create a functional component only to realize that you need one of these class-only features later. In these situations, it’s a hassle to manually convert to a function into a class.

功能组件不支持状态，引用或生命周期方法。他们也不能扩展PureComponent。有时，您将创建功能组件只是为了意识到以后需要这些仅基于类的功能之一。在这种情况下，手动将函数转换为类很麻烦。

Edit: Instead of converting to a class, you can enhance existing functional with lifecycle methods, state, and more via recompose.

编辑：您可以使用生命周期方法，状态等通过recompose增强现有功能，而不必转换为类。

2.凌乱的差异 (2. Messy Diffs)

After you’ve finished the conversion, the diff is noisy. Even a trivial one-line change results in a multi-line code review.

完成转换后，差异比较大。即使是很小的单行更改也会导致多行代码检查。

Here’s an example of converting a functional component to a class so that it can be declared a PureComponent.

这是将功能组件转换为类以便可以将其声明为PureComponent的示例。

If this component were declared as a class from the start, the true intent of the commit would be crystal clear — it would require a 4 character change:

如果从一开始就将此组件声明为类，则提交的真正意图将非常清楚-需要更改4个字符：

Conversion obscures the component’s history by creating the illusion that the component has been largely rewritten when in fact you may have made a very trivial change. The person who does the conversion will be “blamed” for writing many lines that they merely changed for conversion reasons.

转换掩盖了组件的历史，从而产生了这样一种错觉，即实际上您可能进行了很小的更改时，组件已被大量重写。进行转换的人会因撰写许多行仅出于转换原因而更改的行而受到“指责”。

3.较小的信噪比差异 (3. Minor Signal to Noise Differences)

Compare a minimal class to a function, and the differences are minor. Remember, constructors are optional without state.

将最小类与函数进行比较，差异很小。记住，构造函数是可选的，没有状态。

Correction: Oops! I forgot the functional style can be a one-liner with a simple arrow function:

纠错：糟糕！我忘记了功能样式可以是带有简单箭头功能的单线：

const Hello = ({greeting, firstName}) => <div>{greeting} {firstName}</div>

4.不一致 (4. Inconsistency)

Function and class components look different. This inconsistency can slow developers down as they shift between the two styles.

函数和类组件看起来有所不同。当开发人员在两种样式之间切换时，这种不一致会使开发人员放慢速度。

In classes, you say this.props, in functions, you say props.
在类中，您说this.props ，在函数中，您说props 。
In classes, you declare a render function. In functions, you don’t.
在类中，您声明一个渲染器功能。在函数中，您不需要。
In classes, you destructure at the top of render. In functions, you destructure in the function’s argument list.
在类中，您可以在渲染顶部解构。在函数中，可以在函数的参数列表中解构。
In classes, you declare default props below the component (or via class properties if you’re willing to use a stage-3 feature). In functions, you declare default props using default arguments.
在类中，您可以在组件下方声明默认道具(如果愿意使用Stage-3功能，则可以通过类属性声明)。在函数中，您使用默认参数声明默认道具。

These subtle differences add friction for new devs, and the context switching leads to mistakes for experienced devs too.

这些细微的差异增加了新开发人员的摩擦，而上下文切换也导致经验丰富的开发人员出错。

5.类是OO开发人员所熟悉的 (5. Classes Are Familiar to OO Developers)

Yes, JavaScript’s classes are certainly different than Java and C# classes. But anyone working in OO-land on the server is likely to find this simple rule easy to understand:

是的，JavaScript的类肯定不同于Java和C＃类。但是在服务器上的OO-land工作的任何人都可能会发现此简单规则易于理解：

“A React component is a class that extends React.Component.”

“ React组件是扩展React.Component的类。”

Adding a nuanced conversation about how and when to use plain functions adds confusion for OO devs who are already accustomed to being required to use classes for everything. Now I’m not saying this mindset is healthy — the React community fosters more of a functional mindset. But, one must acknowledge that functional components create mental-model friction for OO devs.

对于已经习惯于被要求对所有事情都使用类的OO开发人员，添加有关如何以及何时使用普通函数的细微对话会增加混乱。现在我并不是说这种思维方式是健康的-React社区培养了更多的功能思维方式。但是，必须承认功能组件为面向对象的开发人员造成了心理模型上的摩擦。

6.尚无性能优势 (6. No Performance Benefits, Yet)

While the React team has alluded to the chance that functional components will be faster or more efficient in the future, that’s not the case yet. So one could argue functional components are currently a premature optimization.

尽管React团队暗示了功能组件将来会更快或更高效的可能性，但事实并非如此。因此有人可以说功能组件目前是过早的优化。

And since functional components require conversion to a class to implement today’s performance tweaks like shouldComponentUpdate and PureComponent, they’re actually more of a hassle to optimize for performance today.

而且，由于功能组件需要转换为一个类才能实现今天的性能调整(如shouldComponentUpdate和PureComponent)，因此实际上它们更麻烦地优化当今的性能。

Update: With React 16.6+, you can declare “pure” functional components via React.memo.

更新：使用React 16.6+，您可以通过React.memo声明“纯”功能组件。

7.另一个决定 (7. Yet another decision)

Finally, JavaScript developers already have a ridiculous number of decisions to make. Banning functional components eliminates a decision: Always create a class.

最后，JavaScript开发人员已经做出了许多荒唐的决定。禁止功能组件可消除以下决定：始终创建类。

摘要 (Summary)

I’m still a fan of functional components. But now I recognize they’re not necessarily a slam dunk for everyone. So, as usual, consider the tradeoffs. ?

我仍然喜欢功能组件。但是现在我意识到他们并不一定是每个人的灌篮。因此，像往常一样，要考虑折衷。？

See other downsides or benefits? Chime in below.

看到其他缺点或好处？钟声在下面。

寻找更多关于React的信息？ ⚛️ (Looking for More on React? ⚛️)

I’ve authored multiple React and JavaScript courses on Pluralsight (free trial).

我已经在Pluralsight上编写了多个React和JavaScript课程 ( 免费试用 )。

Cory House is the author of multiple courses on JavaScript, React, clean code, .NET, and more on Pluralsight. He is principal consultant at reactjsconsulting.com, a Software Architect at VinSolutions, a Microsoft MVP, and trains software developers internationally on software practices like front-end development and clean coding. Cory tweets about JavaScript and front-end development on Twitter as @housecor.

Cory House是JavaScript，React，干净代码，.NET等课程的多本课程的作者，并且还提供了有关Pluralsight的更多课程。他是reactjsconsulting.com的首席顾问， VinSolutions的软件架构师，Microsoft MVP，并且在软件开发方面对国际软件开发人员进行了培训，例如前端开发和简洁编码。 Cory在Twitter上以@housecor表示关于JavaScript和前端开发的推文。