lake of constance with mountain behind

7 Best Practices einer React App

Vorwort des Autors:

7 Jahre React liegen hinter mir und mindestens 25 Apps habe ich bereits mit ReactJs entwickelt.

In dieser Zeit durfte ich jede menge Erfahrung sammeln.

Diese Erfahrung ist heute wahres Gold wert und in diesem Beitrag lernst Du 7 unserer "Best Practices" im Umgang mit komplexen React Applikationen kennen.

1. Verwende TypeScript

Dieser Punkt steht nicht ohne Grund auf Platz 1 dieser Liste.

Viele Kritikpunkte treffen TypeScript und das schürt zu Recht eine gewisse Skepsis. Die Haltung von TypeScript ist aufwändig. Das Erlernen und das konsequente Einhalten der Regeln, die solch ein Tooling verlangt, rechtfertigt diese Denkweise durchaus.

Doch Achtung: Hier wird kurzsichtig gedacht..

Allein Typensicherheit ist den Overhead schon absolut wert. Beinahe täglich komme ich mit Code in Berührung, den ich oder Andere vor langer Zeit entwarfen und jedes Mal aufs Neue, bin ich dafür dankbar mit TypeScript gearbeitet zu haben.

Typescript macht es der IDE leicht, mir bei Code zu helfen, ihn zu refactoren und erklärt mir Funktionen im Detail on the fly.

Wenn Du bis heute noch keinen Kontakt mit TypeScript hattest, bleib unbesorgt. Im Grunde ist TypeScript nichts anderes als Javascript mit ein paar Extras.

Das wichtigste Feature ist mit Abstand die Typensicherheit.

Doch TypeScript bringt auch noch weitere Features mit, die deine Entwicklung beflügeln können. So kannst du zum Beispiel Javascript coden als schrieben wir das Jahr 2100. Features, auf die ein Javascriptler Jahre lang warten muss, bis sie die verschiedenen Stages durchlaufen haben, sind im TypeScript schon heute sauber implementiert. Du kannst diese Spracheigenschaften bereits heute verwenden, als sei das selbstverständlich.

Auch nach Jahren ist dein Code immer noch verständlich. Für Dich und vor allem für deine Partner ist das ein enormer Vorteil.

Vanilla Js ist im Refactoring eher unterqualifiziert aufgestellt, da es für IDE's viel schwerer zu verstehen ist als TypeScript. Du hilfst sozusagen Deiner IDE, Dir beim Coden zu helfen. Ihr geht also eine Symbiose ein.

Für noch leichteren Zugang, kann sich aus TypeScript-Code kinderleicht eine Dokumentation generieren lassen.

Wenn Du Hilfe beim Einstieg oder der Entwicklung benötigst, scheu Dich nicht, uns zu schreiben.

TypeScript - JavaScript that scales.
TypeScript brings you optional static type-checking along with the latest ECMAScript features.

2. Denke in Komponenten

Früher wurden Webseiten entwickelt. Heute entwickelt man Apps, die nach Webseiten aussehen

Aus dem alten Konstrukt der Webseite, kommen Denkweisen, wie zum Beispiel das Entwickeln von einzelnen HTML Seiten.

Diese Denkweise klebt wie ein zäher Kaugummi im Gehirn der alt eingesessenen Webdesigner und Programmierer.

Aus diesem Grund, denken viele Entwickler in Seiten oder in Views und vergessen dabei die Modulartität der App und dass eine Seite in Wirklichkeit aus vielen unabhängigen Elementen besteht, die wir heutzutage Komponenten nennen.

Komponenten sind bewegliche und anpassbare Elemente einer Ui. Sie sind völlig alleinstehend und haben keine Kenntnis über das große Ganze.

Achtung! Dieser Satz ist wichtig und zieht sich durch den gesamten Beitrag.

Komponenten sind in sich geschlossen

Dies ist, wie oben beschrieben, einer der wichtigsten Punkte dieses Beitrags.

Bei Weblake verfolgen wir den Ansatz, dass eine Komponente keine imports außerhalb ihrem eigenen Directory verwendet. Die einzigen Abhängigkeiten, die eine Komponente verwendet, sind npm Pakete.

Eine Komponente ist eine eigenständige Einheit. Sie wird entwickelt, um genau ein Problem zu lösen.

Tests kommen mit in die Komponente

In anderen Sprachen als JavaScript kommt es vor, dass Entwickler Tests als eigenständigen Teil einer Applikation ansehen. Compiler sind nur schwer konfigurierbar und so kommt es dazu, dass Dateien, die während der Entwicklung gebraucht werden, nicht im Produktivcode enthalten sein dürfen.

JavaScript ist hier anders. Wir transpilen zwar auch, doch ist JavaScript hier mega entspannt.

Leider begegnet man dennoch häufig folgendem Konstrukt:

tests
   components
     Component
source
   components
     Component

Hier gibt es einen Ordner für Tests und einen Ordner für Source-Dateien.

Der Ordner, in welchem sich die Tests befinden, gleicht dem Ordner in dem sich die Komponenten befinden, doch ist an der Wurzel der eigentlichen Applikation, die entwickelt wird, getrennt.

Eine folgenschwere Entscheidung.

Von Modularität der Software kann hier nicht mehr die Rede sein. Wiederverwendbarkeit adé. Willst Du eine Komponente in einer anderen Applikation weiter verwenden, musst Du darauf achten, den Test mitzunehmen.

Wir achten darauf, dass eine Komponente, - wie oben beschrieben - eine eigenständige Einheit bildet. Sie sollte auf keinen Fall in die Architektur der App verwickelt werden.

Lösen kannst Du das ganz simpel, indem Du in jeder Komponente einen eigenen Platz für all ihre Tests schaffst. So trägt eine Komponente all ihren Code in sich und ist in sich geschlossen.

Component
   __tests__

Baue deine Komponenten atomar auf

Atomic Design ist in aller Munde. Das Konstrukt ist einfach und wirkungsvoll.

Die komplette Ui wird in atoms, molecules, organisms, templates und pages unterteilt.

Wisse aber, das Atomic-Design nicht in Stein gemeißelt ist.

In manchen Apps verwenden wir nur atoms, molecules und organisms. In Anderen fügen wir Einheiten, wie zum Beispiel forms hinzu.

Atomic Design

Entwickle Funktionale Komponenten

Klassen waren gestern - heute arbeitet man funktional.

Components and Props – React
A JavaScript library for building user interfaces

3. Nutze React.memo und React.useMemo

Performance steht oben auf der Prioritätenliste. Die Kontrolle darüber zu haben, wie sich deine App rendert und wie oft kritische Funktionen aufgerufen werden, ist unabdingbar, um eine schnelle App zu entwickeln.

Hier schaffen Dir, die im React enthaltene Methoden ´memo´ und ´useMemo´ Abhilfe und unterstützen Dich, wo sie nur können.

Memo stammt von Memorize und wie der Name schon vermuten lässt, merken sich diese Funktionen ihren Ausgabewert.

React.memo wird mit 2 Funktionen gefüllt. Einer schwergewichtigen Funktion, wie z.B. das Rendern einer Komponente und einer leichtgewichtigen Funktion, deren einzige Aufgabe darin besteht, zu bestimmen, ob die schwergewichtige Funktion ausgeführt werden soll oder nicht.

Doch wir wollen hier nicht React erklären.
Klicke auf den Link, um mehr zu erfahren.

React Top-Level API – React
A JavaScript library for building user interfaces

4. Entwickle Bibliotheken

Ein Booster in der Entwicklung von Apps sind Bibliotheken. Das gilt nicht nur für die Anderen, sondern auch für Dich. Doch ist das Entwickeln von Bibliotheken zu Beginn ein wenig anspruchsvoll.

Hier ein paar Tipps zur Entwicklung von Libraries.

Entwerfe eine saubere Api

Nichts ist angenehmer, als das Entwickeln mit Frameworks, die intuitiv und verständlich sind. Die Api ist das Frontend Deiner Library und Du solltest sie auch als solche betrachten. Api-design sollte ein wichtiger Begriff für Dich sein.

Nutze NPM oder eine private Registry

Installiere Deine eigenen Bibliotheken auf dem selben weg, auf dem Du Bibliotheken von anderen Entwicklern installierst. Ob Du deine Bibliothek anderen zur Verfügung stellst, bleibt dir überlassen. Doch sie von einer Registry zu installieren und zwanglos überall verwenden zu können, macht Dich beweglich und sorgt gleichzeitig für Ordnung.

Nutze Lerna, oder ähnliche Tools

Schnell kommt eins zum anderen und die Anzahl Deiner Pakete wächst. Beim Versuch mehrere Pakete parallel zu organisieren, kommt man schnell an seine Grenzen.

Schwierig wird es vor allem, wenn die eine Bibliothek, abhängig ist von einer Anderen.

Lerna verwaltet Npm-Pakete für Dich und macht die Verwaltung von zig Bibliotheken im gleichen Projekt zum Kinderspiel.

Lerna verlinkt Deine Bibliotheken untereinander, sodass Du immer die aktuellste Version Deiner Bibliothek im node_modules Verzeichnis hast und sie nicht erst publizieren und installieren musst.

lerna/lerna
:dragon: A tool for managing JavaScript projects with multiple packages. - lerna/lerna

Single-Responsibility-Prinzip

Eine Funktion löst ein Problem und das so richtig gut.
Sie tut nicht mehr, als ihr aufgetragen wird, ist allerdings offen für Erweiterungen.

Das ist einer der Leitsätze unter denen wir arbeiten.

https://en.wikipedia.org/wiki/Single-responsibility_principle

Don't repeat yourself

Ein weiterer Leitsatz ist DRY.

Unterteile ruhig in sehr kleine Teile. Das erlaubt dir Codestücke wiederzuverwenden.

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

YAGNI richtig verstehen und anwenden

Yagni bedeutet nicht, die Zukunft außer Acht zu lassen.
Dein Code muss offen für Veränderung sein.

https://de.wikipedia.org/wiki/YAGNI

5. Trenne Logik und Representation

Ein wichtiger Punkt, ist die Trennung von Logik und Representation.

Komponenten sind pur und haben keine Sideeffects. Sie reagieren auf Properties und verzichten auf interne State-Verwaltung. Komponenten wissen nicht, was außerhalb ihres kleinen Mikrokosmos vor sich geht. Sie machen keine ApiCalls und lauschen auch nicht auf Events.

Sie kennen die Struktur der Applikation nicht und sind kontextlos.

Bei Weblake entwickeln wir React Apps immer nach folgendem Muster:

source
 logic
// Alles was mit der Logik zu tun hat
 view
   // Alles was mit dem View zutun hat

React bedient zwar den Viewlayer, doch auch der hat Logik und sei es nur, das Anfragen und Vorbereiten von Daten aus Api's.

6. Nutze ein Tool um States zu verwalten

Am Statemanagement-Firmament tun sich unzählige Helferlein auf, die Dir versprechen, den Zustand Deiner Applikation sauber zu verwalten.

Es ist im Grunde egal, auf welches Pferd Du setzt. Hauptsache Du verzichtest auf setState und useState.

Redux hat sich bei uns bewährt. Jedoch muss es nicht zwangsläufig auch für Dein Projekt der passende Sparringpartner sein.

Redux - A predictable state container for JavaScript apps. | Redux
A predictable state container for JavaScript apps.

7. Verabschiede Dich von Abkürzungen

In eigener Sache.

Wie oft saß ich schon fluchend vor dem Display. Stundenlange Einarbeitung in Fremdcode und das nur, weil sich der nette Entwickler von nebenan, gerne mal zwei Buchstaben spart. Auf der anderen Seite, wühle ich mich manchmal durch Code, der sich so leicht liest, als würde mir der Entwickler, der ihn verfasste, von seinem letzen Urlaub erzählen.

Der Grund für dieses Phänomen, sind Abkürzungen.

Abkürzungen machen sich auf lange Sicht nicht bezahlt. Sie schänden das Codebild und dienen absolut keinem anderen Zweck, als dem faulen Entwickler vorzugaukeln, er wäre ein super krasser Hacker, der in Hieroglyphen coden kann.

Ich bekomme schon Herzrasen, wenn ich mir die Dokumentation von Expressjs und deren 'req' und 'res' Parameter anschaue. Mal ganz abzusehen von Ramda und anderen komplexen Bibliotheken.

Eine schöne Alternative wäre es, request und response zu schreiben.
Was hat der Entwickler damit gewonnen req und res zu verwenden?

Wir bei Weblake stehen auf sauberen Code. Abkürzungen sind in unseren Projekten strickt untersagt. Die Vergangenheit lehrte uns, dass Du für jedes weggelassene Zeichen, 100 fach bestraft wirst und das zu Recht.

Wir haben den Anspruch, Code zu verfassen, der sich beim Lesen von selbst erklärt. Code, den beim möglichen Wechseln des Entwicklers jeder sofort versteht. Code, den man liest wie ein Buch. Hierbei sind Abkürzungen ein absolutes Tabu.

Zusammenfassung:

React macht sich vor allem in komplexen Apps mehr als bezahlt.

Allerdings kann man vieles falsch machen und sich damit in tobendes Gewässer manövrieren. Am großen Ende, sagen die hier aufgeführten Punkte alle das Selbe aus: Halte Ordnung.

Du möchtest Dein Unternehmen beflügeln und brauchst weiteres Wissen aus der Praxis? Schreib mir gerne eine Nachricht, egal auf welcher Plattform.

Seaground
Weblake Logo (shark, mountain, sea)

weblake

Impressum

copyright © 2019 weblake ug (haftungsbeschränkt)

  • Wir verwenden 🍪Cookies, um Dein Nutzererlebnis zu verbessern

    Datenschutz