Ich sah diese Zeile als eine Antwort auf eine andere Frage hier:
"componentWillMount sollte componentDidMount sein, andernfalls werden Ereignisemitter im Knoten verloren gehen."
und ich verstehe es nicht wirklich. Kann jemand das genauer erklären?
Weitere Informationen:
Beim Erstellen einer reaktiven Anwendung mit flux berechnet eine untergeordnete Komponente als Teil des anfänglichen Renderns 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 auf componentWillMount verschiebe, scheint dies das Problem zu beheben, aber das obige Zitat legt nahe, dass dies eine schlechte Idee ist?
Ist schwer zu verstehen, was dieses Zitat ohne mehr Kontext bedeutet. Was ich Ihnen sagen kann ist, dass es große Unterschiede zwischen den beiden Methoden gibt.
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) angehängt wurde.
Was Sie wirklich brauchen, hängt von Ihrem Anwendungsfall ab. Im Allgemeinen wird componentDidMount verwendet, um mit anderen Bibliotheken (wie jQuery) zu integrieren, es bietet eine Möglichkeit, das von der Komponente gerenderte HTML zu modifizieren.
Ich empfehle Ihnen, diese Links zu lesen:
Ich denke, die vorherrschende Weisheit, dass Listener in componentDidMount gesetzt werden sollten, weil sie Probleme bei isomorphen Anwendungen verhindert, ist ein Fehler. Ich denke, dass in 98% der Fälle für nicht-isomorphe Anwendungen Listener in componentWillMount und componentDidMount auf die gleiche Weise funktionieren, aber es ist konzeptionell falsch und in den 2% der Fälle (wie das Beispiel im Original gegeben) Frage) es wird das Falsche tun.
Es gibt Git-Problemdiskussionen und -kommentare im React-Quellcode, was nahelegt, dass es bevorzugt wäre, dass componentWillMount überhaupt nicht auf dem Server aufgerufen wurde, aber wenn dies nicht der Fall ist, werden beim Vergleich der Prüfsummen Probleme erzeugt der Server prerender dem Client initial rendern. Wenn componentWillMount auf dem Server vorhanden ist, bedeutet dies, dass es in diesem Fall nicht als Teil des Komponentenlebenszyklus ausgeführt wird. Dies wird jedoch als Entschuldigung dafür verwendet, es nicht als Teil des Lebenszyklus in jedem Fall zu zählen.
Tatsächlich 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 Listener nicht 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 Reihenfolge des Dokuments registrieren. Der Vorteil der Dokumentreihenfolge besteht darin, dass Sie die ausstehenden Ereignisse beim erneuten Rendern von Komponenten ausräumen können (z. B. takeRecords für MutationObserver ). Dann können Sie sicherstellen, dass das Dokument von oben nach unten und nicht von unten wiedergegeben wird hoch und wandelt die Rendering-Komplexität von Polynom in linear um.
Darüber hinaus gibt es keine Gefahr zwischen dem ersten Rendern und dem Registrieren des Zuhörers, bei dem sich der Store ändern kann, ohne ein Rendering auszulösen. Dadurch wird die Ansicht nicht mit dem Store synchronisiert (das Beispielproblem in der ursprünglichen Frage) ). Wenn der Listener in componentDidMount registriert ist, müssen Sie entweder sicherstellen, dass der Store nicht in componentDidMount -Rufen in untergeordneten Elementen geändert wird, oder erzwingen Sie ein erneutes Rendern / erneutes Synchronisieren nach der Registrierung des Listeners, was in% erfolgt. co_de% wird in umgekehrter Dokumentenreihenfolge ausgeführt, die eine Polynomkomplexität sein kann (abhängig davon, wie / ob die React componentDidMount aggregiert sind).
Tags und Links javascript reactjs reactjs-flux flux