Peguei um exemplo TodoList para refletir meu problema, mas obviamente meu código do mundo real é mais complexo.

Eu tenho algum pseudo-código como este.

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>,
     );
  }

});

Todos os meus dados são imutáveis e o PureRenderMixin é usado adequadamente e tudo funciona bem. Quando um dado Todo é modificado, apenas o pai e o todo editado são renderizados novamente.

O problema é que, em algum momento, minha lista cresce à medida que o usuário está rolando. E quando um único Todo é atualizado, leva cada vez mais tempo para renderizar o pai, chameshouldComponentUpdate em todos os todos e, em seguida, renderize o todo todo.

Como você pode ver, o componente Todo possui outro componente que não os dados Todo. São dados necessários para renderização por todos os todos e são compartilhados (por exemplo, podemos imaginar que exista um "displayMode" para todos). Ter muitas propriedades torna oshouldComponentUpdate faça um pouco mais devagar.

Além disso, usandoReactCSSTransitionGroup parece diminuir um pouco também, poisReactCSSTransitionGroup tem que se render eReactCSSTransitionGroupChild mesmo antes doshouldComponentUpdate de todos é chamado.React.addons.Perf mostra queReactCSSTransitionGroup > ReactCSSTransitionGroupChild a renderização é desperdiçada em tempo para cada item da lista.

Então, até onde eu sei, eu usoPureRenderMixin mas com uma lista maior, isso pode não ser suficiente. Ainda não tenho performances tão ruins, mas gostaria de saber se existem maneiras fáceis de otimizar minhas renderizações.

Qualquer ideia?

Editar:

Até agora, minha grande lista é paginada; portanto, em vez de ter uma grande lista de itens, agora divido essa grande lista em uma lista de páginas. Isso permite ter melhores desempenhos, já que cada página pode implementarshouldComponentUpdate. Agora, quando um item muda em uma página, o React precisa chamar apenas a função de renderização principal que itera na página e chamar a função de renderização a partir de uma única página, o que faz com que muito menos iteração funcione.

No entanto, meu desempenho de renderização ainda é linear ao número da página (O (n)) que tenho. Portanto, se eu tenho milhares de páginas, ainda é o mesmo problema :) No meu caso, é improvável que isso aconteça, mas ainda estou interessado em uma solução melhor.

Tenho certeza de que é possível obter desempenho de renderização O (log (n)) em que n é o número de itens (ou páginas), dividindo uma lista grande em uma árvore (como uma estrutura de dados persistente) e onde cada nó tem o poder de causar um curto-circuito na computação comshouldComponentUpdate

Sim, estou pensando em algo semelhante a estruturas de dados persistentes como Vector in Scala ou Clojure:

No entanto, estou preocupado com o React porque, até onde eu sei, pode ter que criar nós dom intermediários ao renderizar os nós internos da árvore. Isso pode ser um problema de acordo com o caso de usuário (e pode ser resolvido em versões futuras do React)

Além disso, como estamos usando Javascript, pergunto-me se o Immutable-JS suporta isso e torna os "nós internos" acessíveis. Vejo:https://github.com/facebook/immutable-js/issues/541

Editar: link útil com minhas experiências:Um aplicativo React-Redux pode realmente ser dimensionado e, digamos, Backbone? Mesmo com a seleção novamente. No telemóvel