Warum componentWillMount sollte nicht verwendet werden?

Feuern server-Aufruf zum abrufen von Daten in componentWillMount life-cycle-Methode eine schlechte Praxis?

Ist und warum es besser ist, componentDidMount.

InformationsquelleAutor Lokesh Agrawal | 2017-09-04
  1. 18

    UPDATE: componentWillMount bald veraltet.

    Zitieren @Dan Abramov

    In zukünftigen Versionen Reagieren wir erwarten, dass componentWillMount wird Feuer mehr als einmal in einigen Fällen, so sollten Sie verwenden componentDidMount für Netzwerk-Anforderungen.

    Lesen Sie mehr hier.

    • Dies ist, was ich Lesen irgendwann zurück, hatte aber nie einen berechtigten Grund, warum es mehrfach aufgerufen wird.
    • Dies ist ein link nur die Antwort, das erklärt nicht das "warum" Kontext der Frage. Keine der anderen Antworten die Frage beantworten, besser, so sollte man dies nicht akzeptierte Antwort.
    InformationsquelleAutor Lyubomir
  2. 19

    UPDATE - Mai /2018

    Es gibt ein neues feature für das reagieren in einer Arbeit genannt async-rendering.

    Wie reagieren v16.3.2 diese Methoden sind nicht "sicher" zu verwenden:

    • componentWillMount
    • componentWillReceiveProps
    • componentWillUpdate

    können Sie mehr darüber Lesen Sie in der docs.

    Als Allgemeine Regel nicht verwenden componentWillMount an alle (wenn Sie das es6 class syntax). verwenden Sie die constructor Methode statt.

    Diese life-cycle-Methode ist gut für ein sync-Zustand Initialisierung.

    componentDidMount in der anderen hand ist gut für async-state manipulation.

    Warum?

    Gut, wenn Sie eine asynchrone Anfrage in der constructor /componentWillMount Sie es tun, bevor render wird aufgerufen, wenn die asynchrone operation beendet hat, die render Methode, die die meisten wahrscheinlich schon fertig, und keinen Punkt zu setzen, den "initial state" in dieser Phase ist es?.

    Ich bin mir nicht sicher, ob dies der Fall hier, aber die meisten der Fälle, dass der Entwickler will zu initiieren Zustand asynchron in componentWillMount ist zu vermeiden, eine zweite render nennen. aber Sie können nicht vermeiden, es kann Sie, wie oben erwähnt, ist render wird ausgelöst, bevor überhaupt der asynchronen operation fertig ist.

    Also, die beste Zeit zu nennen, ein asynchroner Vorgang ist nach einer render genannt hat und die Komponente montiert ist (Sie könnte den mount null oder eine leere <div/>) und dann Holen Ihre Daten, der Zustand und machen es neu Rendern bzw.

    • Korrekte, Erklärung mit async Aufrufe Beispiel gibt genug Grund für die nicht-Verwendung componentwillmount. Danke Kumpel 🙂
    InformationsquelleAutor Sagiv b.g
  3. 6

    componentDidMount ist der beste Ort, um Aufrufe zum abrufen von Daten aus zwei Gründen:

    1. Mit componentDidMount macht deutlich, dass die Daten nicht geladen werden, erst nach der ersten machen. Sie müssen setup ursprünglichen Zustand ordnungsgemäß, so dass Sie nicht bekommen undefined Staat, der die Fehler verursacht.

    2. Wenn Sie brauchen, um machen Ihre app auf dem server componentWillMount wird zweimal aufgerufen werden(auf dem server wieder an den client), das ist wahrscheinlich nicht das, was Sie wollen. Wenn die Daten laden von code in componentDidMount wird sichergestellt, dass nur solche Daten holt man sich aus dem client. Im Allgemeinen sollten Sie nicht fügen Sie Nebenwirkungen componentWillMount.

    InformationsquelleAutor mradziwon
  4. 2

    Ich verstehe es so, einer von das größte Gründe, die zu tun hat mit Einrichtung die richtigen Erwartungen für die Entwickler Lesen Sie den code.

    Wenn wir componentWillMount es ist verlockend, zu denken, dass die fetch-Zeit haben passieren, dann die Komponente "Tat" montieren, und dann das erste Rendern passieren wird. Aber, dass es nicht der Fall ist. Wenn wir einen asynchronen Aufruf (wie ein API-Aufruf mit dem Versprechen), wird die Komponente laufen eigentlich render vor der fetch zurückkehren können, und legen Sie die Komponente Staat (oder ändern Sie die Redux Staat, oder was auch immer).

    Wenn wir stattdessen verwenden componentDidMount ist, dann ist es klar, dass die Komponente gerendert wird mindestens einmal, bevor Sie wieder alle Daten (da die Komponente bereits hat mount). Also, durch Erweiterung, ist es auch klar, dass wir haben, um den ursprünglichen Zustand in einer Weise, so dass die Komponente nicht zu brechen auf die erste ("leer") machen.

    InformationsquelleAutor jonahe
  5. 2

    Komponente Montage-life-cycle ist

    • Konstruktor()
    • componentWillMount() /UNSAFE_componentWillMount()(reagieren 16)
    • render()
    • componentDidMount()

    Konstruktor und componentWillMount beide rufen, bevor render () - Aufruf verantwortlich ist, die für die Seitendarstellungen.

    Hier Zustand initialisiert wird, erfolgt im Konstruktor und die api sind in der componentDidMount, weil der asynchronen Aufrufe.

    ComponentWillMount war gut im initialisierten Zustand ist, bevor ES6 beim Konstruktor nicht da war. Aber jetzt ComponentWillMount ist für nichts gut und reagieren-team ist, es zu denken nach, reagieren 17.

    Zusätzlich oben, reagieren Sie bewegt haben, zu reagieren Faser-Architektur, um zu vermeiden, unnötige re-rendering und die performance zu verbessern, zu reagieren, hat beschlossen, sich zu bewegen Weg von componentWillMount, componentWillReciveProps und componentWillUpdate Methoden.

    • es ist nicht zu beantworten, warum componentWillMount ist unsicher und wird nicht verwendet, für die Daten abrufen.
    • Dies ist die offizielle Aussage Reagieren. Sie führten es aus gutem Grund und wegen des ES6 wird es nicht mehr benötigt wird, so Reagieren team selbst erklären es als unsicher. und empfiehlt die Verwendung von Konstruktor() über componentWillMount().
    InformationsquelleAutor Devinder Suthwal
Schreibe einen Kommentar