Reagieren Sie die Route ohne erneutes Rendering

Question

So habe ich eine einfache React/Flux App mit Backbone-Router. Ich habe einen Fall, wo der Benutzer ein Objekt erstellt, und der Pfad aktualisiert von /object/new zu . Es ist jedoch nicht erforderlich, die Seite neu zu rendern, da die Komponente die gleiche ist, und aufgrund der damit verbundenen Speicheraktualisierung, nachdem der ajax-create-Aufruf zurückgegeben wurde, aktualisiert sie sich selbst.

Derzeit habe ich gepatcht nur den Router, ein Verfahren zu machen, die einfach die URL aktualisiert, und tatsächlich die Route nicht-spezifische Methode getroffen. Das fühlt sich hacky an und behandelt nicht wirklich Fälle, in denen einige Komponenten (dh ein Widget) hinzugefügt/entfernt werden müssen (zumindest beseitigt es die Verantwortung zu wissen, welche Komponenten aus dem Router gerendert werden müssen), sondern die primäre Die Benutzeroberfläche muss nicht erneut gerendert werden.

Also das lässt mich mit drei Fragen:

1. Was die Art und Weise für den Umgang mit url Veränderungen reagieren, die sich über die Komponenten nicht benötigen?
2. Was ist mit URL-Änderungen, die nur bestimmte Komponenten hinzufügen/ändern?
3. Sollten Filialen für die Einleitung von Routing-Ereignissen verantwortlich sein?

Answer 1

Einer der wichtigsten Wertvorstellungen von React ist, dass das Rendern sehr, sehr billig ist.

Dies bedeutet, dass Sie übermäßig ohne negative Effekte neu zu rendern. Dies ist eine komplette 180 von Backbone, wo Rendering sehr teuer ist, was zu Logik führt, die Sie suchen, nämlich wie Renderings vermieden werden können.

Unter der Haube reagiert diese Prüfung für Sie durch den virtuellen DOM mit dem DOM diffing. Mit anderen Worten: Wenn Sie die exponierte Renderfunktion in React verwenden, rendern Sie das DOM nicht wirklich, sondern beschreiben nur den neuen Zustand des DOM mit Javascript.

In der Praxis bedeutet dies, dass, wenn Sie nicht viele Werte berechnen, können Sie ständig rerender bei 60 Bildern pro Sekunde ohne Optimierungsschritte.

Dies gibt Ihnen die Freiheit zu voll „wieder machen“, wenn auch nur sehr wenige Dinge auf Ihrer App tatsächlich ändern.

So ist mein Rat eigentlich nichts versuchen, die ganze Seite zu verhindern Reagieren auf rerender, auch wenn sich nichts ändert. Diese Art von Logik erhöht die Komplexität, und Sie können diese Komplexität umsonst vermeiden, indem Sie eine Routenänderung bedingungslos wiederholen. Dies ist auch aus konzeptioneller Sicht sinnvoll, da die Route nichts anderes als ein globaler App-Zustand ist.

Die Freiheit, dies zu können, ist einer der Hauptgründe, warum React großartig ist.

Es ist ein klassischer Fall von "vorzeitige Optimierung ist die Wurzel allen Übels".

Zum Beispiel: Ich habe manchmal global rerender die gesamte DOM-Hierarchie auf mouse Ereignisse, und es gibt keine Auswirkungen auf die Leistung zu beobachten.

Als allgemeine Regel, denken Sie an einen Redender als eine Null-Kosten-Operation. Jetzt haben Sie möglicherweise einige teure Operationen in Ihren React-Komponenten. Wenn dies der Fall ist, können Sie die Lifecycle-Methoden von React verwenden, um diese bei Bedarf auszuführen.Sehen Sie sich speziell sollteComponentUpdate, componentWillReceiveProps und componentWillUpdate.

Wenn Sie Flux verwenden und sich an das Paradigma der Unveränderlichkeit halten, können Sie sehr billige Referenzgleichheitsprüfungen von Staat und Requisiten machen, um Arbeit auf Nachfrage zu erledigen. Damit können Sie die Leistung verbessern.

Mit der Methode sollteComponentUpdate können Sie einen Render-Aufruf verhindern, wenn es zu viel Rechenleistung erfordert. Allerdings würde ich dies nur tun, wenn es aufgrund einer teuren Operation, die Sie selbst implementiert haben, zu einer verbesserten Leistung führt.

In Ihrem Fall würde ich den Route-Status in der Root-Komponente injizieren, sie als Requisiten in die Kinder des Stamms injizieren und implementieren sollteComponentUpdate auf ihnen, um ein Render zu verhindern.