Wie bieten die zustandslosen Komponenten von React 0.14 Leistungsverbesserungen ohne shouldComponentUpdate?

Diese Frage hat sich in meinem Kopf herumgesprochen, seit ich die Versionshinweise (und andere verwandte Hype) zu React 0.14 gelesen habe. Ich bin ein großer Fan von React und denke, dass zustandslose Komponenten ( https: //facebook.github). io / react / blog / 2015/09/10 / react-v0.14-rc1.html # stateless-function-components ) sind eine hervorragende Idee, sowohl um das Schreiben solcher Komponenten zu vereinfachen als auch um die Absicht dieser im Code auszudrücken Komponenten sollten in Bezug auf das konsistente Rendern für dieselben Requisitendaten "rein" sein.

Die Frage ist: Wie wird es React möglich sein, diese zustandslosen Komponentenfunktionen zu optimieren, ohne auf die Probe zu stellen und davon auszugehen, dass Requisitenreferenzen nicht nur unveränderlich sind, da sie nicht innerhalb der Komponente manipuliert werden sollten, sondern sich auch niemals ändern können außerhalb des Komponentenlebenszyklus? Der Grund dafür, dass "reguläre" Komponenten (auch als Stateful-Komponenten bezeichnet - mit anderen Worten, die Komponenten, die den gesamten Lebenszyklus durchlaufen; componentWillMount, getInitialState usw.) eine optionale Funktion "shouldComponentUpdate" haben, ist, dass React nicht davon ausgeht, dass alle Requisiten und Zustandsreferenzen sind völlig unveränderlich. Nachdem Komponenten gerendert wurden, können sich bestimmte Eigenschaften der Requisitenreferenzen ändern, sodass dieselbe "Requisiten" -Instanz später möglicherweise unterschiedliche Inhalte hat. Dies ist teilweise der Grund, warum die Verwendung vollständig unveränderlicher Strukturen sehr aufregend war und warum die Verwendung von Om mit React große Leistungssteigerungen bieten könnte. Da die dort verwendeten unveränderlichen Strukturen garantierten, dass eine bestimmte Instanz eines Objekts niemals mutiert werden konnte, sollte SollteComponentUpdate wirklich günstige Referenzgleichheitsprüfungen für Requisiten und Status durchführen (http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ ).

Ich habe versucht, mehr Informationen darüber herauszufinden, habe aber nirgendwo etwas gefunden. Ich kann mir nicht vorstellen, welche Leistungsverbesserungen bei zustandslosen Komponenten vorgenommen werden könnten, ohne davon auszugehen, dass Requisitendaten aus unveränderlichen Typen bestehen. Vielleicht eine vorläufige Analyse nicht unveränderlicher Requisitentypen, um zu erraten, ob "Requisiten" und "nextProps" die repräsentieren gleiche Daten?

Ich habe mich nur gefragt, ob jemand Insiderinformationen oder andere aufschlussreiche Erkenntnisse dazu hat. Wenn React anfangen würde zu fordern, dass Requisitentypen "vollständig unveränderlich" sind (lassen Sie Vergleiche mit Referenzgleichheit zu, um zu bestätigen, dass sich die Daten nicht geändert haben), dann wäre dies meiner Meinung nach ein großer Schritt nach vorne, aber es könnte auch eine große Änderung sein.

Genau darauf gibt es im Reaktionsprojekt ein Github-Problem.

Laut diesem Github-Problem Kommentar:

Bei komplexen Komponenten übersteigt das Definieren von shouldComponentUpdate (z. B. reines Rendern) im Allgemeinen die Leistungsvorteile zustandsloser Komponenten. Die Sätze in den Dokumenten weisen auf einige zukünftige Optimierungen hin, die wir geplant haben, wobei wir keine interne Instanz für zustandslose Funktionskomponenten zuweisen (wir rufen nur die Funktion auf). Wir halten die Requisiten usw. möglicherweise auch nicht weiter. Winzige Optimierungen. Wir sprechen nicht über die Details in den Dokumenten, da die Optimierungen noch nicht implementiert sind (zustandslose Komponenten öffnen die Türen zu diesen Optimierungen).

und aus einer anderen Antwort desselben Mitarbeiters:

Es gibt Diskussionen darüber, ob Sie ein pureRender-Flag für die Funktion setzen oder ihr erlauben könnten, am Lebenszyklus von shouldUpdate teilzunehmen, aber das ist derzeit nicht implementiert. Derzeit können zustandslose Funktionen nicht rein gerendert werden.

Schließlich erhalten wir aus diesem Kommentar eine Antwort auf Ihre Frage:

Wir machen standardmäßig kein reines Rendern, aber wir bieten Ihnen möglicherweise eine Möglichkeit, sich in Zukunft anzumelden.

Also müssen wir sehen, wie sie uns für 'pureRender' entscheiden lassen :)