Wann braucht ein Projekt React?

Sie wissen, wann ein Projekt HTML und CSS benötigt, weil es im Grunde nur daraus besteht. Wann Sie zu JavaScript greifen, ist ziemlich klar: wenn Sie Interaktivität oder Funktionalität benötigen, die nur JavaScript bieten kann. Früher war es ziemlich klar, wann wir zu Bibliotheken griffen. Wir griffen zu jQuery, um die Arbeit mit dem DOM, Ajax und die Bewältigung von Cross-Browser-Problemen mit JavaScript zu vereinfachen. Wir griffen zu Underscore, um Hilfsfunktionen zu erhalten, die JavaScript allein nicht hatte.

Da der Bedarf an diesen Bibliotheken schwindet und wir einen massiven Anstieg neuer Frameworks sehen, würde ich argumentieren, dass es nicht mehr so klar ist, wann man zu ihnen greifen sollte. Ab welchem Punkt brauchen wir React?

Ich benutze React hier nur als Platzhalter für ziemlich große JavaScript-Framework-Dinger. Vue, Ember, Svelte... egal. Ich verstehe, dass sie nicht alle gleich sind, aber wann man zu ihnen greifen sollte, finde ich gleichermaßen nebulös.

Hier ist mein Take.

✅ Weil es viel Zustand gibt.

Selbst "Zustand" ist ein etwas nebulöses Wort. Stellen Sie sich Dinge wie diese vor

• Welches Navigations-Element ist aktiv
• Ob ein Button deaktiviert ist oder nicht
• Der Wert einer Eingabe
• Welche Akkordeon-Abschnitte aufgeklappt sind
• Wenn ein Bereich geladen wird
• Der angemeldete Benutzer und das Team, dem er angehört
• Ob das, woran der Benutzer arbeitet, veröffentlicht ist oder ein Entwurf

Geschäftslogik-Artige Dinge, mit denen wir regelmäßig zu tun haben. Zustand kann auch einfach Inhalt sein

• Alle Kommentare zu einem Artikel und die Details, aus denen sie bestehen
• Der aktuell angezeigte Artikel und all seine Metadaten
• Ein Array verwandter Artikel und die Metadaten für diese
• Eine Liste von Autoren
• Ein Aktivitätsprotokoll der letzten Aktionen eines Benutzers

React hilft Ihnen nicht, diesen Zustand zu *organisieren*, es sagt nur: Ich weiß, dass Sie sich mit Zustand *befassen* müssen, also nennen wir ihn einfach *Zustand* und haben programmgesteuerte Wege, diesen Zustand zu setzen und abzurufen.

Vor React haben wir vielleicht in Bezug auf den Zustand *nachgedacht*, aber meistens haben wir ihn nicht als direktes Konzept verwaltet.

Vielleicht haben Sie den Ausdruck "Single Source of Truth" gehört? Oft haben wir den DOM als unsere Single Source of Truth behandelt. Sagen wir zum Beispiel, Sie müssen wissen, ob ein Formular auf Ihrer Website abgeschickt werden kann. Vielleicht würden Sie überprüfen, ob $(".form input[type='submit']).is(":disabled"), weil all Ihre Geschäftslogik, die damit zu tun hatte, ob das Formular abgeschickt werden konnte oder nicht, letztendlich das deaktivierte Attribut dieses Buttons geändert hat. Der Button wurde also zur De-facto-Quelle der Wahrheit für den Zustand Ihrer App.

Oder sagen Sie, Sie müssten den Namen des ersten Kommentarautors eines Artikels herausfinden. Vielleicht würden Sie schreiben $(".comments > ul > li:first > h3.comment-author).text(), weil der DOM der einzige Ort ist, der diese Information kennt.

React sagt uns quasi

1. Fangen wir an, all diese Dinge als Zustand zu betrachten.
2. Ich gehe noch einen Schritt weiter: Zustand ist ein Stück JSON, also ist es einfach zu handhaben und funktioniert wahrscheinlich gut mit Ihrem Backend.
3. Und noch eins drauf: Sie erstellen Ihr HTML mit Teilen dieses Zustands, und Sie müssen sich nicht direkt mit dem DOM befassen, ich kümmere mich um all das für Sie (und mache es wahrscheinlich besser/schneller als Sie es getan hätten).

✅ Um Spaghetti zu bekämpfen.

Das hängt stark mit den Zustandsthemen zusammen, über die wir gerade gesprochen haben.

"Spaghetti"-Code ist, wenn Ihnen Organisation und Struktur des Codes entglitten sind. Stellen Sie sich wieder ein Formular auf Ihrer Website vor. Es enthält Geschäftslogik, die sich speziell mit den Eingaben darin befasst. Vielleicht gibt es eine Zahleneingabe, die beim Ändern das Ergebnis einer Berechnung daneben anzeigt. Das Formular kann auch abgeschickt werden und muss validiert werden, also ist dieser Code vielleicht woanders in einer Validierungsbibliothek. Vielleicht wird das Formular deaktiviert, bis Sie sicher sind, dass alle JavaScript woanders geladen sind, und diese Logik ist woanders. Vielleicht erhalten Sie beim Absenden des Formulars Daten zurück, die Logik und Handhabung erfordern. Nichts wirklich Überraschendes hier, aber Sie sehen, wie schnell das verwirrend werden kann. Wie kann ein neuer Entwickler in dem Projekt, der sich dieses Formular ansieht, alles nachvollziehen, was vor sich geht?

React fördert das Erstellen von Dingen in Modulen. Dieses Formular wäre also wahrscheinlich entweder ein eigenes Modul oder aus kleineren Modulen zusammengesetzt. Jedes davon würde die Logik behandeln, die für es direkt relevant ist.

React sagt: *Nun, Sie werden den DOM nicht direkt auf Änderungen und so überwachen, weil der DOM meiner ist und Sie nicht direkt damit arbeiten dürfen*. Warum fangen Sie nicht an, diese Dinge als Teil des Zustands zu betrachten, ändern den Zustand, wenn Sie es brauchen, und ich kümmere mich um den Rest, rendere neu, was neu gerendert werden muss.

Es sei darauf hingewiesen, dass React selbst Spaghetti nicht vollständig löst. Sie können immer noch Zustand an allen möglichen seltsamen Orten haben, Dinge schlecht benennen und Dinge auf seltsame Weise verbinden.

Nach meiner begrenzten Erfahrung ist es Redux, das Spaghetti wirklich tötet. Redux sagt: Ich werde den *gesamten* wichtigen Zustand global verwalten, nicht Modul für Modul. Ich bin die absolute Quelle der Wahrheit. Wenn Sie den Zustand ändern müssen, ist ein ziemlicher *Aufwand* damit verbunden (ich habe es so gehört, und es gefällt mir). Es gibt Reducer und dispatchte Actions und so weiter. Alle Änderungen folgen dem Aufwand.

Wenn Sie den Redux-Weg gehen (und davon gibt es natürlich Variationen), erhalten Sie wirklich soliden Code. Es ist viel schwieriger, Dinge kaputt zu machen, und es gibt klare Spuren, wie alles miteinander verbunden ist.

✅ Viel DOM-Management.

Das manuelle Handhaben des DOM ist wahrscheinlich die größte Ursache für Spaghetti-Code.

1. HTML hier einfügen!
2. Etwas hier herausreißen!
3. Dieses Gebiet auf dieses Ereignis beobachten!
4. Hier ein neues Ereignis binden!
5. Neue Inhalte kommen! Wieder einfügen! Sicherstellen, dass sie die richtigen Ereignisbindungen haben!

All diese Dinge können jederzeit und von überall in einer Anwendung geschehen, die zu Spaghetti geworden ist. Echte Organisation wurde aufgegeben, und es ist zurück zum DOM als Quelle der Wahrheit. Es ist schwer genau zu wissen, was für ein bestimmtes Element vor sich geht, also fragt jeder einfach den DOM, macht, was er tun muss, und hofft, dass es niemanden anderen stört.

React sagt: Sie dürfen sich nicht direkt mit dem DOM befassen. Ich habe ein virtuelles DOM und kümmere mich darum. Ereignisse werden direkt an die Elemente gebunden, und wenn Sie etwas tun müssen, das über etwas hinausgeht, das direkt in diesem Modul handhabbar ist, können Sie auf eine Art zeremonielle Weise Dinge in höheren Modulen aufrufen, aber auf diese Weise kann der Brotkrumenpfad verfolgt werden.

*Kompliziertes* DOM-Management ist eine weitere Sache. Stellen Sie sich eine Chat-App vor. Neue Chat-Nachrichten können erscheinen, weil eine Echtzeit-Datenbank neue Daten von anderen Chattern hat und einige neue Nachrichten angekommen sind. Oder Sie haben selbst eine neue Nachricht getippt! Oder die Seite wird zum ersten Mal geladen und alte Nachrichten werden aus einem lokalen Datenspeicher geladen, damit Sie sofort etwas sehen. Hier ist ein Twitter-Thread, der das verdeutlicht.

❌ Nur weil. Es ist die neue heiße Sache.

Etwas zu lernen, nur um des Lernens willen, ist großartig. Tu das.

Ein Projekt für Kunden und echte menschliche Benutzer zu bauen, erfordert sorgfältigere Überlegungen.

Ein Blog zum Beispiel hat *wahrscheinlich* keine der Probleme und passt in kein Szenario, das React zu einer guten Wahl machen würde. Und weil es keine gute Wahl ist, ist es wahrscheinlich eine *schlechte* Wahl, da es komplizierte Technologie und Abhängigkeiten für etwas einführt, das sie nicht erfordert.

Und doch, Grauzone. Wenn dieser Blog eine SPA ("Single Page App", d. h. keine Browser-Aktualisierung) ist, die aus Daten von einem Headless CMS erstellt wurde und ein schickes serverseitiges Rendering hatte... nun, vielleicht ist das wieder React-Territorium.

Das Web-App-CMS, das diesen Blog erstellt? Vielleicht eine gute Wahl für React, wegen all des Zustands.

❌ Ich mag einfach JavaScript und möchte alles in JavaScript schreiben.

Leuten wird gesagt, hey, ich habe Leuten gesagt: Lerne JavaScript. Es ist riesig. Es treibt alle möglichen Dinge an. Es gibt Jobs darin. Es wird nicht verschwinden.

Erst in der jüngsten Web-Geschichte ist es möglich geworden, JavaScript nie zu verlassen. Sie haben Node.js auf der Serverseite. Es gibt viele Projekte, die CSS aus dem Mix reißen und Stile über JavaScript handhaben. Und mit React ist auch Ihr HTML in JavaScript.

Alles JavaScript! Heil JavaScript!

Das ist alles schön und gut, aber auch hier gilt: Nur weil man es kann, heißt das nicht, dass man es tun sollte. Nicht alle Projekte erfordern das, und die meisten wahrscheinlich nicht.

☯️ Das ist, was ich weiß.

(Es gibt gute Emojis für JA und NEIN, aber VIELLEICHT ist schwieriger!)

Sie lernen. Großartig. Das tun alle. Lernen Sie weiter. Je mehr Sie wissen, desto fundiertere Entscheidungen können Sie über die zu verwendende Technologie treffen.

Aber manchmal muss man mit dem bauen, was man kennt, also werde ich es Ihnen nicht verdenken.

☯️ Da sind die Jobs.

Nicht jeder hat direkten Einfluss darauf, welche Technologie in einem bestimmten Projekt verwendet wird. Hoffentlich haben Sie im Laufe der Zeit Einfluss darauf, aber das braucht Zeit. Eden sagt, sie hat 2 Jahre mit Ember verbracht, weil dort die Jobs waren. Nichts dabei falsch. Jeder muss seinen Lebensunterhalt verdienen, und Ember mag für diese Projekte perfekt gepasst haben.