Como os Componentes sem Estado do React 0.14 oferecem melhorias de desempenho sem shouldComponentUpdate?

Esta pergunta está girando na minha cabeça desde que li as notas de versão (e outras sugestões relacionadas) em torno do React 0.14 - sou um grande fã do React e acho que componentes sem estado ( https: //facebook.github. io / react / blog / 2015/09/10 / react-v0.14-rc1.html # stateless-function-components ) são uma excelente ideia, tanto para a facilidade de escrever esses componentes quanto para expressar em código a intenção que esses componentes devem ser "puros" em termos de renderização consistente para os mesmos dados de adereços.

A questão é: como será possível para o React otimizar essas funções de componentes sem estado sem ficar completamente louco e assumindo que as referências de objetos não são apenas imutáveis, pois não devem ser manipuladas dentro do componente, mas também que nunca podem mudar fora do ciclo de vida do componente? A razão pela qual os componentes "regulares" (também conhecidos como componentes com estado - em outras palavras, os componentes que passam por todo o ciclo de vida; componentWillMount, getInitialState, etc.) têm uma função opcional "shouldComponentUpdate" é que o React não assume que todos os props e referências de estado são completamente imutáveis. Após a renderização dos componentes, certas propriedades das referências de objetos propostos podem mudar e, portanto, a mesma instância "objetos" pode ter conteúdos diferentes posteriormente. Isso é parcialmente porque houve muita empolgação com o uso de estruturas totalmente imutáveis ​​e porque foi dito que o uso do Om com o React poderia oferecer grandes ganhos de desempenho; como as estruturas imutáveis ​​usadas lá garantiam que qualquer instância de qualquer objeto nunca pudesse ser mutada, o ComComponentUpdate deveria executar verificações de igualdade de referência realmente baratas em props e state (http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ ).

Eu tenho tentado descobrir mais informações sobre isso, mas não tenho nenhum lugar. Não consigo imaginar quais melhorias de desempenho poderiam ser feitas em componentes sem estado sem presumir que os dados de adereços consistam em tipos imutáveis. Talvez uma análise preliminar de tipos de adereços não imutáveis ​​para tentar adivinhar se "adereços" e "nextProps" representam mesmos dados?

Eu apenas me perguntei se alguém tinha alguma informação privilegiada ou algumas idéias esclarecedoras sobre isso. Se o React começou a exigir que os tipos de objetos sejam "totalmente imutáveis" (permita comparações de igualdade de referência para confirmar que os dados não foram alterados), acho que seria um grande passo à frente, mas também poderia ser uma grande mudança.

Há um problema no github no projeto react sobre exatamente isso.

De acordo com este comentário da questão do github :

Para componentes complexos, a definição de shouldComponentUpdate (por exemplo, renderização pura) geralmente excederá os benefícios de desempenho dos componentes sem estado. As sentenças nos documentos sugerem algumas otimizações futuras que planejamos, nas quais não alocamos uma instância interna para componentes funcionais sem estado (apenas chamaremos a função). Também podemos não manter os adereços, etc. Pequenas otimizações. Não falamos sobre os detalhes nos documentos porque as otimizações ainda não foram implementadas (os componentes sem estado abrem as portas para essas otimizações).

e de outra resposta do mesmo colaborador:

Há discussões sobre ter um sinalizador pureRender que você pode definir na função ou permitir que ele participe do ciclo de vida shouldUpdate, mas que atualmente não está implementado. No momento, funções sem estado não podem ser renderizadas com pureza.

finalmente, a partir deste comentário , obtemos uma resposta para sua pergunta:

não fazemos renderização pura por padrão, mas podemos fornecer uma maneira de você participar no futuro.

Então, teremos que ver como eles nos permitirão optar por 'pureRender' :)