Heim > Web-Frontend > js-Tutorial > Hören Sie auf, anonyme Funktionen in Requisiten zu verwenden!

Hören Sie auf, anonyme Funktionen in Requisiten zu verwenden!

Mary-Kate Olsen
Freigeben: 2025-01-01 11:13:09
Original
863 Leute haben es durchsucht

Quit Using Anonymous Functions in Props!

Okay, der Titel ist ein bisschen ein Klick-Köder. Es gibt Zeiten, in denen Sie anonyme Funktionen als Requisiten verwenden müssen, aber das ist wahrscheinlich viel seltener, denken Sie. Aber zuerst beschreiben wir das Problem.

Anonyme Funktionen als Requisiten

In Komponentenbibliotheken wie Svelte und React sind anonyme Funktionen, die als Komponenten-Requisiten verwendet werden, zu einer Art fauler Anlaufstelle geworden, die in größerem Maßstab aufzublähen droht.

Ich sehe, dass so viele Entwickler dies tun:

<button onclick={() => handleSubmit()}>Submit</button>
Nach dem Login kopieren
Nach dem Login kopieren

Stattdessen:

<button onclick={handleSubmit}>Submit</button>
Nach dem Login kopieren
Nach dem Login kopieren

Jeder dieser Codeblöcke wird buchstäblich das exakt gleiche Ergebnis erzielen. Der einzige Unterschied besteht darin, dass im ersten Beispiel eine anonyme Funktion eingefügt wurde und diese lediglich eine benannte Funktion ohne Argumente aufruft.

Verstehen Sie, warum die Verwendung des anonymen Ansatzes ein Problem sein könnte? Jedes Mal, wenn diese Schaltfläche gerendert wird, wird eine brandneue Anon-Funktion erstellt und im Speicher gehalten. Wenn Sie zehn davon auf derselben Seite gerendert haben, werden zehn verschiedene anonyme Funktionen im Speicher gespeichert.

Jetzt könnten Sie sagen: „Okay, aber wie oft werde ich mehr als, sagen wir, zehn oder zwanzig interaktive Elemente auf einer Seite haben?“ Und die Antwort lautet: „Man denkt vielleicht, dass es sich um einen Grenzfall handelt, aber es kommt häufiger vor, als man vermuten würde. Und mit guten Gewohnheiten könnte man genauso gut für den Grenzfall bereit sein!“

Ein Paradebeispiel dafür, wo dies ein Problem sein kann, sind größere Tabellen oder Listen mit interaktiven Funktionen, wie etwa dem Löschen oder Bearbeiten einer Zeile oder eines Elements. Wenn Sie beispielsweise eine Komponente vom Typ Datenraster auf Ihrer Seite haben und Ihre Paginierung dafür beispielsweise 100 Zeilen pro Seite beträgt, dann ist jede anonyme Funktion, die jede Zeile erstellt, 100 Mal vorhanden. Wenn Sie über ein Kontrollkästchen verfügen, das in jeder Zeile etwas ausführt, sowie über die Schaltflächen „Bearbeiten“ und „Löschen“, werden jetzt 300 anonyme Funktionen im Speicher gespeichert, zusammen mit den ursprünglich drei benannten und deklarierten Funktionen, die von den anonymen Funktionen aufgerufen werden.

Noch schlimmer ist es, wenn man Tricks wie Pre-Rendering anwendet, aber aus Effizienzgründen die nächste Datenseite ausblendet. In diesem Beispiel befinden sich jetzt 600 anonyme Funktionsinstanzen im Speicher.

Okay, warum machen die Leute das dann?

Mir fallen mindestens zwei Gründe ein, warum diese Gewohnheit so weit verbreitet und tief verwurzelt ist.

Reaktivität oder anderes gewünschtes Verhalten

Zumindest in Svelte gibt es Zeiten, in denen Sie dies tun müssen, um sicherzustellen, dass die Funktion reaktiv aufgerufen wird. Es kann auch andere Arten von Situationen geben, in denen Sie dies tun müssen, damit Ihre Logik wie vorhergesagt funktioniert, und obwohl es schon ein paar Jahre her ist, seit ich mit React gearbeitet habe, gibt es bestimmt auch einige ähnliche Beispiele in dieser Bibliothek.

Aber das sind Randfälle, die Sie bei Bedarf beim Codieren ansprechen können.

Vereinfachung der Übergabe von Funktionsparametern

Dieser ist wahrscheinlich der häufigste Übeltäter. Es ermöglicht Ihnen, einen Zustand direkt an die Funktion zu übergeben, sodass Sie es leichter verstehen und damit arbeiten können, wenn Sie sich zum ersten Mal mit einer UI-Bibliothek wie Svelte oder React vertraut machen. Das ist vielleicht der Grund, warum die meisten Tutorials anonyme Funktionen als Requisiten zeigen.

Hier ist ein Beispiel (in Svelte 5):

<button onclick={() => handleSubmit()}>Submit</button>
Nach dem Login kopieren
Nach dem Login kopieren

Schön und sauber, oder? Aber wir haben dieses potenzielle Leistungsproblem, wenn wir Hunderte von Instanzen dieser Schaltfläche auf dieser Seite haben. Wie können wir dies umgestalten, um potenziell leistungsfähiger zu sein?

Die einfachere Lösung

Wie es in der Programmierung oft der Fall ist, besteht eine einfache und unkomplizierte Lösung darin, sicherzustellen, dass wir einzelne Komponenten für Dinge wie EditButton erstellen und dann die Produkt-ID nur auf diese Instanz beschränken. Wir müssen also nichts an unsere Handlerfunktion übergeben, da sie sich in einer diskreten Komponente befindet, die diese Produkt-ID bereits kennt. Aus diesem Grund ist es im Allgemeinen gut, wenn der Code eher modular als monolithisch ist.

Wenn möglich, sollten Sie auf jeden Fall zuerst versuchen, diese Lösung zu finden. Und beachten Sie, dass wir diese anonyme Funktion einfach nicht benötigen, da unsere Komponente auf die Verarbeitung nur einer Produkt-ID beschränkt ist. Stattdessen kann unsere Komponentenfunktion direkt damit umgehen.

<button onclick={handleSubmit}>Submit</button>
Nach dem Login kopieren
Nach dem Login kopieren

Die komplexere Lösung

Aber es gibt Zeiten, in denen wir die Update-Logik aufgrund der Systemarchitektur oder aus anderen Gründen nicht auf einen lokalen Maßstab wie diesen beschränken können. Um mit einer solchen Situation umzugehen, tun wir etwas, das, ja, etwas komplexer und, ich hasse es, das zu sagen, etwas weniger deklarativ ist als das Senden einer anonymen Funktion als Requisite. Aber es ist immer noch sehr gut lesbar und funktioniert für unsere Zwecke, nicht eine Menge anonymer Funktionen in den Speicher zu schieben.

Dazu gehört die Verwendung von Datenattributen für das HTML-Element, das das von Ihnen verarbeitete Ereignis (z. B. Klick) abruft. Und es sieht so aus:

// EditButton.svelte

<script>  
  // productId is sent to this component as a prop
  let { productId } = $props()
</script>

const onEditToggle = (productId) => {
  // Do some stuff with productId...
}

<button onclick={() => onEditToggle(productId)}>
  Edit
</button>
Nach dem Login kopieren

Sehen Sie, was dort passiert? Wir fügen die Produkt-ID in ein benutzerdefiniertes Datenattribut im HTML-Schaltflächenelement in EditButton ein. Wenn die Handlerfunktion ausgelöst wird, kann sie die Produkt-ID direkt aus dem Datenattribut des Elements abrufen.

Jetzt haben wir nur noch eine Funktion, onEditToggle, die im Speicher deklariert ist, und alles andere verweist nur per Referenz darauf.

Das Gleichgewicht zwischen Lesbarkeit und Leistung

Mein persönlicher Eindruck ist es, immer mit Code zu beginnen, der so gut modularisiert ist, dass die Weitergabe von Schlüsseldaten über Requisiten direkt an diese Komponente erfolgt, anstatt dass die Komponente monolithisch ist und all dies intern bestimmt werden muss. Das ist es, was ich oben in „Die einfachere Lösung“ beschreibe.

Wenn Sie das absolut nicht können, dann entscheiden Sie sich für die zweite Lösung mit Datenattributen.

Nun könnte man argumentieren, dass die Verwendung von Anon-Funktionen etwas besser lesbar ist als die Handhabung von Datenattributen. Daher ist es zunächst besser, damit anzufangen, sodass Sie sie später einfach anpassen können, wenn Sie auf Leistungsprobleme stoßen.

Ich stimme dieser Denkweise im Großen und Ganzen zu, aber dies ist ein Fall, in dem Komplikationen, die sich daraus ergeben, ein wenig häufig genug sind, um es einfach immer auf die gleiche Weise zu tun. Auf diese Weise müssen Sie nicht darüber nachdenken, ob/wann Sie einen Ansatz gegenüber dem anderen verwenden. Beide funktionieren, und eines muss später nicht umgestaltet werden, wenn Sie feststellen, dass Sie diese Leistungsprobleme haben.

Zum Schluss noch eine Einschränkung

Es ist durchaus möglich, dass Svelte dies während der Transpilierung irgendwie handhabt, um diese anonymen Funktionen irgendwie zu glätten. Ich bin kein Experte für die Laufzeit oder den Compiler von Svelte, um das mit Sicherheit sagen zu können. Aber ich persönlich bin der Meinung, dass dies ein sichereres Muster ist, das für jede JS-Bibliothek gilt, die Sie möglicherweise verwenden, und daher ist es einfach eine bessere Angewohnheit, es im Voraus zu übernehmen.

Was denkst du? Haben Sie Kontrapunkte? Oder kann ich vielleicht Einblicke in die Vorgänge auf Laufzeit- und Kompilierungsebene mit Svelte geben, die meine Meinung ändern könnten? Lass es mich in den Kommentaren wissen!

Das obige ist der detaillierte Inhalt vonHören Sie auf, anonyme Funktionen in Requisiten zu verwenden!. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Quelle:dev.to
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Neueste Artikel des Autors
Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage