2015-06-17 17 views
8

Ich sah diese Zeile als eine Antwort auf eine andere Frage hier:Warum sollte addChangeListener in componentDidMount anstelle von componentWillMount sein?

"ComponentWillMount sollte ComponentDidMount, sonst werden Sie Ereignis Emitter in Knoten."

und ich verstehe es nicht wirklich. Kann jemand das genauer erklären?

Weitere Informationen:

Aufbau einer Applikation reagieren mit Flussmittel, als Teil des anfänglichen machen, berechnet eine untergeordnete Komponente einige Daten. Im Idealfall möchte ich nach der Berechnung dieser Daten eine Aktion aufrufen, die den Status des Geschäfts mit einem Teil dieser neuen Daten aktualisiert.

Normalerweise wird beim Aktualisieren des Status des Geschäfts ein Änderungsereignis ausgegeben, das zu einem erneuten Rendern führt. Da der Änderungslistener jedoch erst in componentDidMount (statt in componentWillMount) hinzugefügt wird, kann meine Komponente auf oberster Ebene nicht auf die Änderung achten, die während des anfänglichen Renderns auftritt, und ein erneutes Rendern initiieren.

Wenn ich den addChangeListener zu componentWillMount verschiebe, scheint dieses Problem zu beheben, aber das obige Zitat deutet darauf hin, dass dies eine schlechte Idee ist?

Antwort

3

Ist schwer zu verstehen, was dieses Zitat ohne mehr Kontext bedeutet. Was ich Ihnen sagen kann ist, dass zwischen diesen beiden Methoden große Unterschiede bestehen.

Auf der einen Seite wird componentWillMount aufgerufen, bevor die Komponente tatsächlich zum DOM hinzugefügt wird. Dies ist die letzte Möglichkeit, den Zustand der Komponente zu aktualisieren und sie zu rendern, bevor die Komponente vom Browser gerendert wird.

Auf der anderen Seite wird componentDidMount aufgerufen, sobald die Komponente an das DOM (das echte) angefügt wurde.

Was Sie brauchen, hängt wirklich von Ihrem Anwendungsfall ab. Im Allgemeinen wird componentDidMount verwendet, um mit anderen Bibliotheken (wie jQuery) zu integrieren, es bietet eine Möglichkeit, das HTML zu ändern, das von der Komponente gerendert wird.

Ich schlage vor, Sie diese Links zu lesen:

+0

Das Problem ist, dass, wenn ich das DOM in 'componentDidMount' modifizieren, wenn er bemerkt, dass das DOM von ihm abweichen Virtuelles, gibt es mir Fehler! – ciaoben

+0

Es gibt normalerweise eine Arbeit für solche Dinge. Ich für eine Verwendung Reagieren mit Ace Rich-Text-Editor, jQuery Resizable, jQuery sortierbar und viele andere Dinge, die "außerhalb von React's Welt" arbeiten und hatte keinerlei Probleme. Sie müssen darauf achten, nicht zu ändern, was React gerendert hat, aber Sie können in den meisten Fällen neue Elemente hinzufügen. Ist schwer zu helfen ohne weitere Informationen über Ihre Aufgabe. – damianmr

4

Ich denke, die vorherrschende Meinung, dass Zuhörer sollten in componentDidMount gesetzt werden, weil es Probleme verhindert in isomorphe Anwendungen sind ein Fehler. Ich denke, in 98% der Fälle für nicht-isomorphe Anwendungen Einstellung Hörer in entweder componentWillMount und componentDidMount funktionieren auf die gleiche Weise, aber es ist konzeptionell falsch und in den 2% der Fälle (wie das Beispiel in der ursprünglichen Frage gegeben) wird es das falsche tun.

Es gibt Git Problemdiskussionen und Kommentare in der React-Quellcode darauf hindeutet, dass es bevorzugt wäre, dass componentWillMount wurde überhaupt nicht auf dem Server aufgerufen, aber wenn es nicht dann Probleme im Prüfsummentest erstellt werden Server prerender zum Client initial render. Eine componentWillMount auf dem Server bedeutet, dass es in diesem Fall nicht als Teil des Komponentenlebenszyklus ausgeführt wird, aber dies wird als Entschuldigung dafür verwendet, es nicht als Teil des Lebenszyklus in jedem Fall zu zählen.

In der Tat ist componentWillMount genau der richtige Ort, um Listener zu registrieren, wenn Sie keine isomorphe Anwendung erstellen. Wenn Sie eine isomorphe Anwendung erstellen, müssen Sie einige Kompromisse eingehen, da das Prüfsummen-/Lebenszyklusproblem in diesem Fall nicht ideal ist (vielleicht nur für die Serverumgebung testen und dann keine Listener registrieren).

In nicht-isomorphen Anwendungen kann das Hinzufügen von Listenern in componentWillMount in einigen Fällen unnötige erneute Rendervorgänge speichern und sie in der Dokumentreihenfolge registrieren. Der Vorteil der Dokumentreihenfolge besteht darin, dass Sie, wenn Sie eine Möglichkeit haben, ausstehende Ereignisse zu entfernen, wenn Komponenten erneut gerendert werden (z. B. takeRecords auf einer MutationObserver), dann sicherstellen, dass das Dokument von oben nach unten und nicht von unten nach oben gerendert wird Rendering-Komplexität zu linear von Polynom.

Darüber hinaus gibt es keine Gefahr zwischen dem ersten Rendern und dem Registrieren des Listeners, bei dem sich der Store ändern kann, ohne ein Rendering auszulösen, was dazu führt, dass die Ansicht nicht mit dem Store übereinstimmt (das Beispielproblem im Original) Frage). Wenn der Listener unter componentDidMount registriert ist, müssen Sie entweder sicherstellen, dass der Store unter componentDidMount Anrufe in Kindern nicht geändert wird, oder erzwingen Sie ein erneutes Rendern/erneutes Synchronisieren nach der Registrierung des Listeners, was in componentDidMount erfolgt in umgekehrter Reihenfolge getan wird Dokumentreihenfolge, die eine Polynomkomplexität sein kann (abhängig davon, wie/wenn der React aggregiert ist).

Verwandte Themen