React性能：使用PureRenderMixin渲染大列表

Question

我以TodoList为例来反映我的问题，但是显然我的实际代码更加复杂。

我有一些这样的伪代码。

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

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

  renderTodo: function(todo) {
     return <Todo key={todo.id} todoData={todo} x={this.props.x} y={this.props.y} .../>;
  },

  render: function() {
     var todos = this.props.todos.map(this.renderTodo)
     return (
          <ReactCSSTransitionGroup transitionName="transition-todo">
                 {todos}
          </ReactCSSTransitionGroup>,
     );
  }

});

我所有的数据都是不可变的，并且使用了PureRenderMixin并且一切正常。修改待办事项数据后，仅
重新渲染父项和已编辑的待办事项。

问题是，随着用户的滚动，我的列表有时会变得很大。并且，当更新单个待办事项时，渲染
父项，调用shouldComponentUpdate所有待办事项以及渲染单个待办事项所花费的时间越来越多。

如您所见，Todo组件具有与Todo数据不同的其他组件。这是所有待办事项渲染所需的数据并被共享（
例如，我们可以想象待办事项有一个“displayMode”）。具有许多属性会使shouldComponentUpdate执行速度变慢。

此外，使用ReactCSSTransitionGroup似乎有点过于慢下来，因为ReactCSSTransitionGroup必须使自身
ReactCSSTransitionGroupChild甚至在shouldComponentUpdate的待办事项被调用。React.addons.Perf显示ReactCSSTransitionGroup > ReactCSSTransitionGroupChild对列表的每个项目都浪费了渲染时间。

因此，据我所知，我使用的PureRenderMixin列表较大，但这可能还不够。我仍然表现不差，但是想知道是否有简单的方法可以优化我的渲染。

任何想法？

编辑：

到目前为止，我的大列表是分页的，因此，我没有大的项目列表，而是将这个大列表拆分为页面列表。
由于每个页面现在都可以实现，因此可以实现更好的性能shouldComponentUpdate。现在，当项目在页面中发生更改时，React只需调用在页面上迭代的主要render函数，而仅从单个页面调用render函数，这将减少迭代工作。

但是，我的渲染性能仍然与我拥有的页码（O（n））成线性关系。因此，如果我有成千上万的页面，仍然是一个问题：)在我的用例中，这不太可能发生，但我仍然对更好的解决方案感兴趣。

我很确定可以通过将大列表拆分成树（如持久数据结构）以及每个节点的位置来实现O（log（n））渲染性能，其中n是项目（或页面）的数量。有能力使计算短路shouldComponentUpdate

是的，我正在考虑类似于Scala或Clojure中的Vector之类的持久数据结构：

http://hypirion.com/imgs/pvec/9-annotated.png

但是我担心React，因为据我所知，渲染树的内部节点时可能必须创建中间dom节点。根据用例，这可能是一个问题（并可能在以后的React版本中解决）

同样，当我们使用Javascript时，我想知道Immutable-JS是否支持它，
并使“内部节点”可访问。参见：https ://github.com/facebook/immutable-js/issues/541

Answer 1

这是我使用ImmutableJS内部结构完成的POC实现。这不是公共API，因此尚未准备好进行生产，并且
当前无法处理特殊情况，但可以使用。

var ImmutableListRenderer = React.createClass({
  render: function() {
    // Should not require to use wrapper <span> here but impossible for now
    return (<span>
        {this.props.list._root ? <GnRenderer gn={this.props.list._root}/> : undefined}
        {this.props.list._tail ? <GnRenderer gn={this.props.list._tail}/> : undefined}
</span>);
  }   
})

// "Gn" is the equivalent of the "internal node" of the persistent data structure schema of the question
var GnRenderer = React.createClass({
    shouldComponentUpdate: function(nextProps) {
      console.debug("should update?",(nextProps.gn !== this.props.gn));
      return (nextProps.gn !== this.props.gn);
    },
    propTypes: {
        gn: React.PropTypes.object.isRequired,
    },
    render: function() {
        // Should not require to use wrapper <span> here but impossible for now
        return (
            <span>
                {this.props.gn.array.map(function(gnItem,index) { 
                    // TODO should check for Gn instead, because list items can be objects too...
                    var isGn = typeof gnItem === "object"
                    if ( isGn ) {
                        return <GnRenderer gn={gnItem}/>
                    } else {
                        // TODO should be able to customize the item rendering from outside
                        return <span>{" -> " + gnItem}</span>
                    }
                }.bind(this))}
            </span>
        );
    }
})

客户端代码看起来像

React.render(
    <ImmutableListRenderer list={ImmutableList}/>, 
    document.getElementById('container')
);

这是一个JsFiddle ，它记录shouldComponentUpdate列表的单个元素（大小N）更新后的呼叫次数：这不需要调用N次shouldComponentUpdate

此ImmutableJs github 问题中共享了更多实现细节