Begründung zur falschen Verwendung von useEffect

Der am häufigsten falsch verwendete Hook in React ist mit Sicherheit useEffect. Wir haben dafür mehrere Gründe, nicht nur einen. Lassen Sie uns jeden einzelnen von ihnen aus meiner Sicht erkunden.

Lebenszyklus-Erbe

Einer der Gründe, weshalb ich denke, dass es eine größere Wirkung hat, ist, dass wir in der Pre-Hooks-Ära Klassen verwendet haben. Für diejenigen, die in dieser Zeit mit der Verwendung von React begonnen haben, ist es üblich, Lebenszyklusmethoden und this.state zu verwenden. Ich habe in diesem Beitrag ein wenig darüber geschrieben. Es gibt Menschen, die die alte, aber goldene Zeit vermissen und deren Einfachheit und Direktheit schätzen. Es ist ein Modell, das ziemlich gut zum allgemeinen Wissen von Programmierern im Allgemeinen passt, die objektorientiertes und imperatives Programmieren lernen, und die mentale Struktur passt einfach zu diesem Modell.

Dann fügten sie Haken hinzu.

Mentaler Paradigmenwechsel

Das Problem ist der Paradigmenwechsel, der stattgefunden hat. Programmierer sind im Allgemeinen mit dem Imperativ und den objektorientierten Paradigmen sehr vertraut, sie werden häufig an Hochschulen und in Kursen gelehrt, wobei vor allem der Imperativ dem allgemeinen Denkfluss eines Menschen folgt.

Wenn Sie zu anderen Paradigmen wie der funktionalen Programmierung wechseln, sehen Sie sich einer umgekehrten Denkweise gegenüber, die der üblichen nicht so nahe kommt. Diese „Umkehrung“ macht es schwieriger zu verstehen.

Reaktive Programmierung hat das gleiche Problem. Es ist ein Wechsel von einer aktiven zu einer passiven Art des Programmierens. Wir sehen es bei der falschen Verwendung von useEffect.

Die meisten "FEHLER" betreffen die Statussynchronisierung. Der Entwickler verwendet also useEffect, um einen Status oder eine Requisite zu verfolgen und basierend auf einer Logik den Status zu ändern. Dieser Fall offenbart die gegenteilige Denkweise, die wir hier brauchen.

Bei OOP und imperativer Programmierung sind Sie aktiv und nehmen die Änderungen und die Logik proaktiv vor. Reaktivität basiert auf dem Gegenteil: Sie reagieren auf eine Chance und geben die Berechnungen an, die das System durchführen soll, wenn sich der Zustand ändert.

Für die meisten Benutzer ist das aktive Festlegen des neuen Status auf dem useEffect der direkte Weg, den Status zu ändern, sodass Sie die Änderung manuell verfolgen und andere Status damit aktualisieren müssen. In den Dokumenten heißt es, dass es NICHT empfohlen wird, aber es gibt keinen klaren Grund dafür.

Die Ableitung in React ist nicht nur aus Leistungsgründen, sondern auch aus konzeptionellen Gründen die empfohlene Methode. React ist eine Ableitungsmaschine und das Ergebnis ist letztendlich die Ableitung der Benutzeroberfläche. Sie müssen sich nicht aktiv um diese Zustandsübergänge und Neuberechnungen kümmern, sie passieren einfach, basierend auf dem deklarativen Code, den Sie geschrieben haben.

React-Dokumente haben dies nicht sehr gut erklärt, nach Hooks haben das React-Kernteam und die Inhaltsersteller keine Vorträge oder Kurse gehalten, in denen diese Konzepte erklärt wurden.

Die konzeptionelle Verwirrung von React

React scheint eine „konzeptionelle Verwirrung“ zu haben, der Übergang zu Hooks ist das deutlichste Beispiel dafür, aber nicht das einzige. Es gibt einen großen Unterschied bei der Verwendung von Hooks, sie basiert auf Reaktivität, und obwohl das React-Kernteam Witze über Reaktivität macht, war es ihre Entscheidung, darauf umzusteigen.

Funktionelle Komponenten sind dafür perfekt. Bei jedem erneuten Rendern wird die Funktion erneut aufgerufen, und alles darin erhält den Status und die aktuelle Version, sodass sich alles, was darin erstellt wird, wie eine Ableitung verhält. Die Rückgabe, die JSX, ist die Ableitung der Benutzeroberfläche.

Aber React ist nicht die perfekte und reine Umsetzung funktionaler Programmierung und Reaktivität. Es nimmt Konzepte und Ideen als Inspiration und führt sie zu einem eigenen Modell zusammen, aber der Kern ist trotzdem vorhanden.

Und das muss klar sein. Auch ohne ein Beispiel für Reaktivität zu sein, nutzt es deren Konzepte, und eine tiefere Kenntnis der Muster erleichtert es einem Entwickler, mit diesen Grundelementen zu denken und Lösungen zu erstellen. Deshalb schreibe ich übrigens diese „Reaktivität in Reaktion“-Reihe.

Sagen Sie den Benutzern nicht nur: „Synchronisieren Sie den Status nicht bei useEffect, das ist schlecht“, sondern erklären Sie, warum es schlecht ist und wie man so denkt, dass „Synchronisierungsstatus“ überhaupt der erste Lösungsgedanke ist.

Fehlen einiger Grundelemente

Diese Ursache verbessert sich, insbesondere in React 19. Asynchrone Ableitungen waren einer der Gründe für die Verwendung von useEffect, aber jetzt müssen wir primitive verwenden, was diese Lücke in gewisser Weise füllt.

Natürlich haben wir immer noch einige Schwachstellen in den Grundelementen, wie zum Beispiel bei dynamischen Ableitungen und anderen Fällen, aber immer mehr React verschiebt die Nebenwirkungen mehr aus dem Hooks-Bereich, wie in diesem Fall von Ref-Callbacks.

Und wir können immer auf Neuigkeiten in der Zukunft hoffen. Ich lade alle ein, alle anderen Reaktivität-in-React-Beiträge zu lesen und konkrete Fälle und Fragen mitzubringen, damit wir diese häufigen Probleme mit Reaktivität erkunden und weitere Lösungen für sie finden können.

Das obige ist der detaillierte Inhalt vonBegründung zur falschen Verwendung von useEffect. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!