Der Lebenszyklus existiert in React mit Hooks nicht

Vor langer, langer Zeit haben wir React mit Klassen verwendet, erinnerst du dich?

Zu dieser Zeit hatten wir das Konzept von Lebenszyklusmethoden, Methoden für die Klassen, die Rückrufe akzeptierten, die zu bestimmten Zeitpunkten ausgeführt wurden. Die großen drei: beim Mounten, beim Aktualisieren und beim Unmounten.

Alte, aber goldene Klassen

Das war wichtig, denn für die Klassenkomponenten wurde das zurückgegebene JSX über die Render-Methode erstellt, der Zustand, der mit diesem der Komponente verknüpft ist, und der App-Entwickler brauchte eine Möglichkeit, zu wissen, welche Aktionen in bestimmten Momenten ausgeführt werden müssen. Wir hatten die Vorstellung von der Zeit auf der Lebensdauer einer Komponente:

• „componentDidMount“ ist der Moment, in dem die Komponente zum ersten Mal gerendert wird und Elemente zum DOM hinzufügt, und es ist der Moment, in dem die Verbindung und Nebenwirkungen wie API-Anfragen gestartet werden.
• Mit ShouldComponentUpdate können Sie Ihre Logik manuell festlegen, um die nächsten Requisiten und den nächsten Status zu vergleichen und einen booleschen Wert zurückzugeben, um zu definieren, ob das erneute Rendern übersprungen werden kann oder nicht.
• „componentDidUpdate“ ist der Moment, in dem sich der Status oder die Requisiten geändert haben, die Render-Methode erneut aufgerufen wird und die Abgleichsänderungen an der Identitätsdifferenz vorgenommen und auf das DOM angewendet werden. Dies ist gut, um den Status mit neuen Requisiten zu synchronisieren und logische Dinge zu erledigen.
• Bei „componentWillUnmount“ würde React die Elemente aus dem DOM entfernen und war ein guter Ort, um Dinge zu bereinigen und Speicherlecks zu vermeiden.

Und natürlich hatten Sie eine wichtige API wie forceUpdate, mit der Sie manuell ein erneutes Rendern auslösen konnten, wenn Sie externe Daten verwenden, die keine Verbindung zu React-Statusaktualisierungen herstellen würden.

Auf konzeptioneller Ebene haben wir eine direktere Möglichkeit, den Ablauf der App zu steuern. Die Lebenszyklusmethoden folgten einem ähnlichen Lebenszyklus eines DOM-Elements. Sie konnten Memo- und ForceUpdates selbst durchführen, die Statussynchronisierung war die Standardmethode für die Logik.

Diese Direktheit wurde als Einfachheit angesehen und das Erlernen dieser Konzepte war im Vergleich zum reaktiven Modell einfacher. Doch dann kamen Haken und veränderten alles.

Die unbenannte Reaktivität

Der Übergang war verwirrend. Um es einfacher zu machen und die konzeptionelle Vision der Entwickler des React-Modells irgendwie beizubehalten, wurde zunächst in vielen Mitteilungen versucht, die Ähnlichkeiten zum Hooks-Modell aufzuzeigen. Um die drei wichtigsten Lebenszyklusmethoden zu kennen, zeigten sie Workarounds mit useEffect.

// componentDidMount
 useEffect(() => {
    // code...

    // componentWillUnmount:
    return function cleanup() {
      // code...
    };
  }, []);

// componentDidUpdate
 useEffect(() => {
    // code...

  }, [dependencyState, dependencyProp]);

Der Großteil des neuen React-Codes, der mit Hooks erstellt wurde, folgte also dieser Idee, und der Beginn der Statussynchronisierung war ein natürlicher Prozess. Um die gleiche Vorstellung von Lebenszyklusmethoden beizubehalten, wurde hier setState aufgerufen und der Neurendervorgang ausgelöst.

Was ist das Problem daran?

Der Synchronisierungsstatus wurde zu einem Problem, die falsche Verwendung von useEffect wurde zu einem Problem, doppelte erneute Renderings wurden zu einem Problem, zu viele erneute Renderings wurden zu einem Problem, die Leistung wurde zu einem Problem.

Zumindest für mich ist dieser Schritt von React etwas verwirrend. Denn die Umstellung auf Hooks war eine Umstellung auf ein reaktives Modell, auch wenn es ein grobkörniges Modell ist. Aber die Kommunikation war, dass sich nichts wirklich Großes geändert habe. Kein Inhalt über die Reaktivitätskonzepte und -theorie, obwohl ich jahrelang mit React gearbeitet habe. Ich habe gerade erst angefangen, Reaktivität wirklich zu verstehen, als ich Ryan Carniatos Blogbeiträge über Reaktivität und Solidität gelesen habe.

Obwohl ich wusste, dass useEffect einen Missbrauch hatte, verstand ich wirklich nicht, warum, und dieser Mangel an konzeptioneller Theorie zur Reaktivität macht es so einfach, Fehler mit Hooks zu begehen. useEffect wurde zum am meisten gehassten Hook und wurde für manche Leute „useFootgun“ genannt. Der Punkt ist, dass es in React eine konzeptionelle Verwirrung gibt, die sich in all den Problemen mit useEffect äußert, die wir heute sehen.

UseEffect-Probleme sind nicht die Ursache des Problems, sondern die Folge.

Was ist mit dem Lebenszyklus mit Haken?

Das ist also die Sache. Im Konzept der Reaktivität gibt es keinen Lebenszyklus.

Man hat eine Veränderung, man reagiert darauf und erzeugt Nebenwirkungen. Auswirkungen sind die Folge, nicht die Ursache. Es gibt keine Statussynchronisierung und keine Konzepte zum Ein- und Aushängen.

Es sollte keine Rolle spielen, ob es das erste, das 10. oder das letzte Rendern vor dem Unmounten ist, und die Hooks kümmern sich übrigens nicht darum, auch nicht um useEffect.

Probieren Sie es aus:

// componentDidMount
 useEffect(() => {
    // code...

    // componentWillUnmount:
    return function cleanup() {
      // code...
    };
  }, []);

// componentDidUpdate
 useEffect(() => {
    // code...

  }, [dependencyState, dependencyProp]);

Sie werden auf Ihrer Konsole sehen, dass beide Funktionen bei jeder Statusaktualisierung ausgeführt werden. Zuerst die Bereinigung und dann der Effekt-Callback. Wenn Sie useEffect mit einem Status oder einer Requisite verwenden, um ein Abonnement durchzuführen, wird jedes Mal, wenn sich die Abhängigkeiten ändern, die Bereinigungsfunktion aufgerufen und dann der neue Rückruf, wodurch das Abonnement erneut ausgeführt wird, jedoch mit den neuen Werten.

Sie sollten Ihren App-Code als vereinfachtes React-Modell betrachten:

function EffectExample() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    console.log('effect', count);

    return () => {
      console.log('clean up', count);
    }
  }, [count]);

  return (
    <button onClick={() => setCount((state) => state + 1)}>
      {count}
    </button>
  )
}

Wenn Sie eine Komponente wie diese haben:

UI = fn(state)

Was Sie wirklich haben, wenn Sie auf die Schaltfläche klicken und 1 zur Zählung hinzufügen, ist konzeptionell in etwa so:

function Example() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount((state) => state + 1)}>
      {count}
    </button>
  )
}

Jeder Klick ruft erneut den Fn mit einem neuen Status auf und generiert eine neue Version der Benutzeroberfläche. Der Status sollte sich durch die Aktion des Benutzers oder durch einen asynchronen Wert ändern, der mit asynchronen Ableitungen erstellt werden sollte.

So bleibt die saubere Idee erhalten:

• Zustandsübergänge führen zu einem neuen Fn-Aufruf
• Mit dem neuen Status erhalten Sie die UI-Beschreibung
• Wenn es anders ist, aktualisieren Sie den Bildschirm.

Ein sauberes und konsistentes Modell.

Es ist Sache des Renderers, sich um das Hinzufügen, Aktualisieren und Entfernen von Elementen auf dem Bildschirm zu kümmern. Auf Komponentenebene kommt es auf Folgendes an:

• wenn sich der Zustand geändert hat
• ob die App die Benutzeraktionen verarbeiten kann
• die zurückgegebene Struktur im JSX.

Hooks und sein reaktives Modell sorgen dafür, dass sich React vom Browser entkoppelt, sodass sich der App-Code weniger darum kümmert, in welchem ​​Moment des Bildschirmrendering-Prozesses Sie sich befinden. Sie erzwingen keine Aktualisierungen und verwalten Memos nicht mehr nach Ihren eigenen Regeln. Dies ist weniger direkt für den App-Entwickler, aber direkter im Hinblick auf das Modell.

Jedes erneute Rendern generiert eine Struktur, React kümmert sich um den Rest.

Das obige ist der detaillierte Inhalt vonDer Lebenszyklus existiert in React mit Hooks nicht. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!