React 0.14 的无状态组件如何在没有 shouldComponentUpdate 的情况下提供性能改进? [英] How will React 0.14's Stateless Components offer performance improvements without shouldComponentUpdate?

问题描述

自从我阅读关于 React 0.14 的发行说明(以及其他相关的炒作)以来，这个问题一直在我脑海中盘旋——我是 React 的忠实粉丝，我认为无状态组件(https://facebook.github.io/react/blog/2015/09/10/react-v0.14-rc1.html#stateless-function-components) 是一个很好的想法，既可以方便编写此类组件，也可以在代码中表达这些组件的意图就相同道具数据的渲染一致而言，应该是纯"的.

问题是:React 怎么可能优化这些无状态组件功能，而无需完全依赖并假设 props 引用不仅是不可变的，因为它们不应该在组件内被操作，而且 也 他们永远不能在组件生命周期之外改变?常规"组件(又名有状态组件 - 换句话说，贯穿整个生命周期的组件；componentWillMount、getInitialState 等)具有可选的shouldComponentUpdate"函数的原因是 React 没有em> 假设所有的 props 和 state 引用都是完全不可变的.组件渲染后，道具引用的某些属性可能会发生变化，因此同一道具"实例稍后可能会有不同的内容.这就是为什么人们对完全不可变结构的使用感到非常兴奋的部分原因，以及为什么据说将 Om 与 React 结合使用可以提供巨大的性能提升；因为那里使用的不可变结构保证任何对象的任何给定实例永远不会被改变，所以 shouldComponentUpdate 可以对 props 和 state 执行非常便宜的引用相等性检查(http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/).>

我一直在尝试了解更多关于此的信息，但一无所获.如果不假设 props 数据将由不可变类型组成，我无法想象 可以围绕无状态组件进行哪些性能改进.也许对非不可变 props 类型进行一些初步分析尝试猜测props"和nextProps"是否代表相同的数据?

我只是想知道是否有人对此有任何内幕消息或其他启发性的见解.如果 React 确实 开始要求 props 类型是完全不可变的"(允许引用相等比较来确认数据没有改变)，那么我认为这将是向前迈出的一大步，但它也可能是一个大变化.

解决方案

避免不必要的分配

如果我理解正确，无状态功能组件被转换为常规组件.来自 来源/p>

function StatelessComponent(Component) {}StatelessComponent.prototype.render = function() {var Component = ReactInstanceMap.get(this)._currentElement.type;返回组件(this.props, this.context, this.updater);};

创建无状态组件的实例时，会分配一个新对象.这个新对象具有生命周期方法，例如 componentWillMount 和 componentWillReceiveProps.我猜计划是不创建这些对象.不创建对象将避免不必要的分配.

避免不必要的检查

实现生命周期方法需要进行许多如下检查:

if (inst.componentWillUpdate) {inst.componentWillUpdate(nextProps, nextState, nextContext);}

可以假设无状态功能组件没有这些生命周期方法.这可能是文档所指的内容，但我不确定.

编辑

删除了关于记忆的内容，这些内容没有很好地回答问题或解释内容.

This question has been going round and round in my head since I read the release notes (and other related hype) around React 0.14 - I'm a big fan of React and I think that stateless components (https://facebook.github.io/react/blog/2015/09/10/react-v0.14-rc1.html#stateless-function-components) are an excellent idea, both for the ease of writing such components and for expressing in code the intention that these components should be "pure" in terms of rendering consistently for the same props data.

The question is: how will it be possible for React to optimise these stateless component functions without going whole-hog and assuming that props references are not only immutable in that they shouldn't be manipulated within the component, but also that they can never change outside of the component lifecycle? The reason that "regular" components (aka stateful components - in other words, the components that go through the whole lifecycle; componentWillMount, getInitialState, etc..) have an optional "shouldComponentUpdate" function is that React does not assume that all props and state references are completely immutable. After components have been rendered, certain properties of the props references may change and so the same "props" instance may have different contents later on. This is partially why there was a lot of excitement over the use of fully-immutable structures and why it was said that using Om with React could offer great performance gains; because the immutable structures used there guaranteed that any given instance of any object could never be mutated, so shouldComponentUpdate could perform really cheap reference equality checks on props and state (http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/).

I've been trying to find out more information about this but haven't got anywhere. I can't envisage what performance improvements could be made around stateless components without presuming that props data will consist of immutable types.. maybe some preliminary analysis of non-immutable props types to try to guess whether "props" and "nextProps" represent the same data?

I just wondered if anyone had any inside information or some otherwise enlightening insights onto this. If React did start demanding that props types be "fully immutable" (allow reference equality comparisons to confirm that data has not changed) then I think that would be a great step forward, but it could also be a big change.

解决方案

Avoiding Unnecessary Allocations

If I understand correctly, stateless functional components are converted into regular components. From the source:

function StatelessComponent(Component) {
}
StatelessComponent.prototype.render = function() {
  var Component = ReactInstanceMap.get(this)._currentElement.type;
  return Component(this.props, this.context, this.updater);
};

When an instance of a stateless component is created, a new object is allocated. This new object has lifecycle methods such as componentWillMount and componentWillReceiveProps. I'm guessing that the plan is to not create these objects at all. Not creating the objects will avoid unnecessary allocations.

Avoiding Unnecessary Checks

Implementing the lifecycle methods requires a number of checks like this:

if (inst.componentWillUpdate) {
  inst.componentWillUpdate(nextProps, nextState, nextContext);
}

Stateless functional components can be assumed to not have these lifecycle methods. That could be what the docs are referring to, but I'm not sure.

EDIT

Removed stuff on memoization, which didn't answer the question or explain stuff well.

这篇关于React 0.14 的无状态组件如何在没有 shouldComponentUpdate 的情况下提供性能改进?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！