Vor mehr als 4 Jahren habe ich mich in
ReactJS verliebt und seitdem habe ich alle Front-End-Anwendungen mit diesem wunderbaren Tool entwickelt. In dieser Zeit haben ich und die Teams, in denen ich arbeiten durfte, eine Reihe von Fehlern gemacht, von denen viele erfolgreich behoben wurden. In schwierigen und teuren Experimenten wurden viele optimale Lösungen gefunden.
Heute möchte ich die kritischsten und schmerzhaftesten Fehler teilen, die häufiger gemacht werden als andere. Bevor ich diesen Artikel schrieb, habe ich natürlich das Internet auf der Suche nach ähnlichen Artikeln studiert, und ich war überrascht, dass die meisten von ihnen veraltet sind und über Dinge sprechen, die 2019 von geringer Relevanz sind. Also habe ich versucht, eine Liste der dringendsten Probleme im Moment zusammenzustellen.
1. Stateful-Komponenten (Klassen) sind schlechter als Hooks
Vielleicht lohnt es sich, mit der sensationellsten
ReactJS- Funktion zu beginnen, die in Version 16.8+ veröffentlicht wurde. Entgegen einiger Überzeugungen wurde diese Funktion von Fehlern früherer Entwicklergenerationen geplagt und löst viele Probleme. Wenn Sie 2019 immer noch Klassenkomponenten anstelle von Hooks verwenden, machen Sie einen großen Fehler und verstehen einfach nicht, was ihr Vorteil ist. Ich werde dies in diesem Artikel nicht im Detail erklären,
dieses wundervolle Video von Den Abramov besser aussehen lassen, aber ich könnte diesen Artikel sonst einfach nicht starten
Dies ist natürlich kein Fehler an sich, aber der Ansatz von Klassen im Vergleich zu Hooks ist viel fehleranfälliger, da bereits viele Artikel darüber geschrieben wurden:
- Die häufigsten Fehler in Ihrem React-Code, die Sie (möglicherweise) machen
- Die 7 häufigsten Fehler, die Entwickler machen
2. Anonyme Funktionen als Requisiten verwenden
Wenn der erste Fehler immer noch als Hommage an die Mode wahrgenommen werden kann, dann rettet Sie das Wissen um den zweiten Fehler vor schlaflosen Nächten und Kopfschmerzen. Schließlich ist sie es, die dafür sorgt, dass die Anwendung so unzureichend funktioniert, dass ihre Benutzer für immer von
ReactJS enttäuscht sein
können . Aber wir möchten, dass Benutzer ihn lieben, genau wie Sie und ich, oder? Um diesen Fehler zu vermeiden, können Sie eine sehr einfache Regel verwenden - übergeben Sie NIEMALS eine anonyme Funktion als Requisiten an die Komponente.
export default function MyOtherComponent() { return ( <MyComponent getValue={i => i.value} /> {/* */} ); }
Eine komplexere Version dieses Fehlers sieht möglicherweise so aus (lesen Sie nicht, wenn Sie mit Redux nicht vertraut sind):
import { connect } from 'react-redux'; import { createStructuredSelector } from 'reselect'; import MyComponent from './MyComponent'; import { fetchProjectData, projectId } from "./store/projects" const mapStateToProps = createStructuredSelector({ projectId, }); const mapDispatchToProps = { fetchProjectData, }; const mergeProps = ( { projectId, ...restState }: any, { fetchProjectData, ...restDispatch }: any, { memberId, ...restOwn }: any ) => ({ ...restState, ...restDispatch, ...restOwn, fetchProjectData: () => fetchProjectData(projectId), }); export default connect( mapStateToProps, mapDispatchToProps, mergeProps )(MyComponent);
In beiden Fällen gelangt natürlich eine anonyme Funktion in die
Requisitenkomponente . Dies ist schlecht, da diese Funktion bei jedem Rendern des übergeordneten Elements auf ein neues Objekt im Speicher verweist. Dies bedeutet, dass es nicht dem vorherigen Objekt entspricht und Ihre Komponente unnötig erfolgreich neu gerendert wird. Es kann die Leistung Ihrer Anwendung so sehr verlangsamen, dass Sie selbst anfangen zu spucken und von
React enttäuscht werden, aber der springende Punkt liegt in ANONYMOUS FUNCTIONS in
Requisiten . Tu es einfach nie - und sei glücklich.
Das Problem ist, dass ein solcher Fehler oft nichts falsch macht. Der Code funktioniert nur für sich selbst - und das war's. Und nichts merklich Schlimmes passiert. Genau bis Sie den anonymen Anruf erneut drücken, um dort Daten vom Server zu empfangen (zweites Beispiel), werden Sie die Schwere des Problems verstehen. Die Anhäufung solcher anonymer Requisiten wird Ihre Bewerbung auf das Niveau von 1995 verlangsamen, als wir die Nachbarn bitten mussten, die Telefonleitung freizugeben, um die Seite herunterzuladen.
Nur ein paar Worte, wie man richtig schreibt. So:
const getValue = i => i.value; return default function MyOtherComponent() { return ( <MyComponent getValue={getValue} /> ); }
import { connect } from 'react-redux'; import { createStructuredSelector } from 'reselect'; import MyComponent from './MyComponent'; import { fetchProjectData, projectId } from "./store/projects" const mapStateToProps = createStructuredSelector({ projectId, }); const mapDispatchToProps = { fetchProjectData, }; export default connect( mapStateToProps, mapDispatchToProps )(MyComponent);
3. Mehrere Reaktionsinstanzen in der Anwendung
Dieser Fehler bezieht sich höchstwahrscheinlich auf die Architektur der gesamten Anwendung und nicht nur auf ReactJS im Besonderen. Aber dieses praktische Problem ist für Entwickler oft zu teuer und für schlaflose Nächte zu oft.
Bitte versuchen Sie nicht, mehr als eine Instanz der React-Anwendung auf einer Seite zu stopfen. Tatsächlich gibt es in der React-Dokumentation kein Verbot für einen solchen Ansatz. In einigen Artikeln (und natürlich in meinen Anwendungen) habe ich sogar Empfehlungen dazu getroffen, ABER die Optimierung dieses Ansatzes und die Koordination aller Teile der Anwendung in diesem Fall beginnt mehr als die Hälfte der gesamten Arbeitszeit in Anspruch zu nehmen. Dies kann leicht vermieden werden: Wenn Sie beispielsweise in Ihrer neuen
React- Anwendung auf einige Ereignisse im Legacy-Code reagieren müssen, können Sie das Ereignismodell verwenden. Zum Beispiel so:
import React, { useCallback, useEffect } from 'react'; export default function MyComponent() { const reactHandlerOfLegacyEvent = useCallback((event) => {}, []); useEffect(() => { document.addEventListener("myLegacyEvent", reactHandlerOfLegacyEvent); return () => { document.removeEventListener("myLegacyEvent", reactHandlerOfLegacyEvent); }; }, [reactHandlerOfLegacyEvent]); return ({}); }
4. Schreiben Sie Ihre eigenen Bibliotheken anstelle von vorhandenem Open Source
Bei diesem Problem geht es überhaupt nicht um
ReactJS , sondern um die gesamte Entwicklung. Während Sie gerade lernen, können Sie durch das Schreiben einer großen Anzahl Ihrer eigenen Bibliotheken schneller wachsen und größer werden. Wenn Sie jedoch an der Spitze der Programmierung stehen möchten, müssen Sie zumindest jede der Open Source-Bibliotheken ausprobieren, die Ihre Probleme lösen. Fragen Sie einfach die Suchroboter, ob es Bibliotheken gibt, die Ihr Problem lösen - sie können solche Fragen perfekt beantworten.
Ich werde kein Beispiel für Bibliotheken geben, die ich selbst benutze, weil Ich weiß, dass die Hälfte von ihnen in ein paar Monaten veraltet sein wird und andere an ihre Stelle treten werden. Und dies scheint der ursprünglichen Aussage zu widersprechen. Und warum sollten Sie Bibliotheken verwenden, die in ein paar Monaten veraltet sind? Die Antwort ist sehr einfach - Sie können die Lösung für die Probleme sehen, die noch nicht vor Ihnen aufgetreten sind. Sie können vorhandene Praktiken verbessern oder anhand des Beispiels von Problemen in vorhandenen Bibliotheken verstehen, wie das Problem viel besser gelöst werden kann. Dies kann nur durch die Interaktion mit der Entwicklungswelt mithilfe von Open Source-Bibliotheken erreicht werden.
5. Angst, den Code eines anderen zu verwenden
Wie der vorherige Fehler gilt dies nicht nur
für ReactJS- Anwendungen, ist jedoch in diesen häufig. Wie oft sehe ich, wie ein großartiger Juni mutig in den Kampf einbricht und Teile des Codes neu schreibt, die großartig funktionieren und keine Probleme haben, nur weil sie über einen der vorherigen 4 Fehler lesen. Ich selbst war so. Aber was gibt es zu betrügen, ich verschwende jetzt oft Zeit, einfach weil Bewegung Leben ist.
Ich habe aber auch gelernt, andere Entwickler, ihre Gedanken und Probleme zu verstehen, auf die sie gestoßen sind. Sehen Sie, wie viel Zeit und Mühe (und nicht umsonst) für die Lösung von Problemen aufgewendet wurde. In 3 von 5 Fällen erhalte ich fast das gleiche Ergebnis wie ich, wenn ich versuche, den Code eines anderen zu „verbessern“. Nur weil Sie zu Beginn einer Aufgabe normalerweise nicht alle Probleme sehen, die in der Zukunft vor Ihnen liegen. Jetzt respektiere ich den Code eines anderen, egal wie seltsam und "veraltet" er mir erscheint. Was ich dir rate.
Vielen Dank
Vielen Dank für das Lesen dieses Artikels und all denen, mit denen ich glücklich bin, zusammenzuarbeiten. Vielen Dank an uns, dass wir unsere Welt interessanter gemacht und weiterentwickelt haben. Lass nicht immer richtig, nicht immer geschickt, sondern bewege dich.
Schreiben Sie in den Kommentaren über die Probleme, auf die Sie gestoßen sind. Vielleicht haben Sie Lösungen für die in diesem Artikel beschriebenen Probleme, die ich verpasst habe (das bin ich mir sicher). Alles Erfolg und gute Laune!