Warum React ?

Mein Name ist Sven und ich bin App / Frontend Developer bei VOIDMOD. In diesem Artikel möchte ich ein wenig auf die Geschichte, die Entwicklung und meine persönliche Meinung zu React eingehen.

‍

Von Angular zu React - alles neu!

Das erste Mal hörte ich von React - wie wahrscheinlich die meisten - im Jahr 2013, bei einer Präsentation von Jordan Walke und Tom Occhino. Zu dieser Zeit arbeitete ich an einem relativ umfangreichen Projekt mit Angular 1, welches zu diesem Zeitpunkt noch sehr neu war. Auch die Idee der SPA (Single-Page-Application) war zu dieser Zeit nicht ansatzweise so verbreitet wie heute.

Angular war besonders zum Prototyping sehr beliebt. Natürlich war es auch dafür geeignet, größere Projekte ordentlich umzusetzen. Sobald man die geschaffene Komfortzone allerdings etwas verlassen musste, stellte uns Angular aber regelmäßig vor Herausforderungen. Trotz allem blieb einer der großen Vorteile, alles unter einem Dach zu haben. Es brauchte wenig - bis keine - zusätzlichen Packages, um die Features zum Laufen zu bekommen.

Da ich aber besonders die Individualität und Flexibilität im Javascript-Bereich sehr schätze, sprach mich React schon deshalb an, weil es eben kein Gesamtpaket war, sondern sehr individuell und mit neuen Ideen.

Der Erfolg gibt dem Team hinter React Recht! Viele andere Frameworks verwenden mittlerweile ähnliche Konzepte.

‍

‍

Was macht React anders?

Virtual-DOM und DOM-Diffing

Mittels des Virtual DOM (eine „in-memory“ Datenstruktur) und dem DOM-Diffing, werden die Änderungen zum aktuellen DOM ermittelt und daraus resultierend nur der Inhalt des Diffs in den DOM übertragen.

So wird sichergestellt, dass jedes Component mit den aktualisierten Props (Eigenschaften) dargestellt wird.

Das besondere daran: Als Entwickler muss man dabei nichts extra konfigurieren oder auf umständliche Weise dafür sorgen, dass ein Component aktuell bleibt. Man beschreibt sein UI einfach so wie es aussehen soll, je nachdem welche Props es erhält. React kümmert sich dann um ein effizientes DOM-Diffing und die Aktualisierung.

‍

‍

Denken in React

„Thinking in React“.

Die deklarativen Components in React arbeiten mit einem unidirektionalen Datenfluss.

Props („Attribute“) eines Components sind statisch und können nicht von diesem selbst geändert werden. Die Daten fließen also stets nur unidirektional - von oben nach unten.

‍

// setName Funktion ist im Parent-Component deklariert
<Greeting 
  name="peter" 
  changeName={(newName) => setName(newName)} 
  />

function Greeting({name, changeName}) {
  function changeName() {
    // 🚫
    name = "Jason";
    
    // 👍🏻
    // Via Callback die Daten vom 
    // übergeordneten Component aus ändern 
    changeName("Jason");
  }
  return <h4>Hello {name}</h4>;
}

Es galt also etwas umzudenken, um das Bestmögliche aus React herausholen zu können. Nach kurzer Eingewöhnung geht dies aber leicht von der Hand und macht Spaß. Besonders wenn man ein älteres Component etwas umbaut und mit Hilfe der React-Devtools sehen kann, dass die Updates/Rerender weniger geworden sind und somit in besserer Performance resultiert.

Um dem sogenannten „Prop-Drilling“ (also das Durchbohren eines Wertes durch unzählige verschachtelte Components) entgegen zu Wirken, gibt es einige Lösungen wie z. B. Redux oder auch „kleinere“ Lösungen wie Zustand. Aber auch React selbst bietet dank der neuen Context-Api eine Variante an, die für die meisten Fälle schon ausreicht.

‍

‍

JSX - HTML in JavaScript?

Viel Stirnrunzeln gab es damals auch bei JSX. Oder wie es auch genannt wurde: HTML in JS.
Aber was man in React schreibt, ist kein „echtes“ HTML. Es ist eine an XML angelehnte Syntaxerweiterung zu JavaScript.

‍

‍

Eine Art HTML in Javascript zu schreiben war anfangs sicher etwas gewöhnungsbedürftig. Unter anderem auch deshalb, weil bestimmte Attribute anders genannt werden mussten. `class` wurde zu `className` etc. pp..

Allerdings wurde man sehr schnell damit vertraut und es war doch merklich einfacher und übersichtlicher als HTML-Element Loops in Attributen zu verpacken.

‍

‍

Etwas mehr Code? Ja, aber es ist für jeden ersichtlich, was dieser Code genau macht und wie man daran etwas verändern oder erweitern kann. Vor allem weil es nur Javascript-Expressions sind (den JSX-Teil mal ausgenommen).

‍

‍

Functional Components mit Hooks

Die Umstellung von den „alten“ Class-Components zu den Functional Components mit Hooks wurde anfangs auch eher skeptisch betrachtet.

Die Class-Components hatten zwar ihre Probleme, wie z. B. die Verwirrung um den Context des „this“-Keywords (welcher JavaScript bedingt ist) oder die langen Schreibweisen und den daraus resultierenden Overhead, allerdings waren sie auf den ersten Blick etwas strukturierter. Auch für Entwickler, die eigentlich eine Sprache schreiben, welche stark auf Klassen basiert, war das Lesen dieser Components etwas einfacher. Es gab allerdings auch Stolpersteine, weil diese Klassen sich nicht immer so verhalten haben, wie man es evtl. erwarten würde.

Die neue Variante mit den „magischen" Hooks bietet aber sehr viele Vorteile. Es ist viel weniger Code notwendig, um Dinge zu verwirklichen. Die Logik lässt sich in selbst geschriebene Hooks auslagern und in anderen Components nahtlos einbinden.

‍

‍

React liefert auch einige Hooks mit, wie z. B. den `useState`-Hook oder den `useEffect`-Hook. Letzterer bietet dabei die Möglichkeit, auf bestimmte Änderungen von Props o.ä. zu reagieren.

Hooks haben aber auch ein paar Einschränkungen. Zum Beispiel müssen sie immer am Kopf der Funktion deklariert werden. Auch ein dynamisches Deklarieren (beispielsweise durch ein If-Else) ist nicht möglich.

‍

‍

Hooks bieten eine gute Möglichkeit, um Funktionalität auszulagern und vor allem in unterschiedlichsten Components wiederzuverwenden. Bevor die neuen Features Einzug in der Release Version von React erhielten, gab Dan Abramov dazu einen sehr interessanten Vortrag.

‍

‍

Mobile Applikationen mit React

‍
Anfangs kaum erst genommen und inzwischen sehr beliebt in der Mobile-Entwicklung: React-Native

Die ersten Releases von React-Native standen noch auf wackeligen Beinen, allerdings konnte man schon das riesige Potential erkennen.

Learn once, write anywhere

Web- und Mobile-Applikationen mit dem gleichen Framework schreiben und zusätzlich noch Code zwischen diesen beiden teilen. Das war die Idee hinter React-Native. Der Aufbau ist fast 1:1 wie bei einer Web-Applikation. Nur bestimmte HTML-Tags müssen durch ihre React-Native Versionen getauscht werden.

‍

‍

Diese speziellen React-Native Components werden im Buildprozess in Native Element umgewandelt. Mit diesem Vorgehen konnte eine React-Native-Applikation eine viel bessere User-Experience bieten als beispielsweise eine HTML-App (Ionic o.ä.).

Inzwischen ist es möglich, React-Native nicht nur für Android und iOS zu verwenden, sondern auch für Windows und macOS. Auch Web-Applikationen lassen sich so umsetzen.

Facebook entwickelte React-Native u. a. auch deshalb, weil sie den Buildprozess ihrer riesigen Apps beschleunigen wollten. Entwickler mussten nach einer Änderung einfach zu lange auf diesen warten, während eine React-Native App einen Hot-Reload in der Entwicklungsumgebung besitzt. Dieser lädt die relevanten Teile der Applikation erneut. Nur in seltenen Fällen ist ein Rebuild der App erforderlich. (Apple bietet inzwischen einen ähnlichen Ansatz mit SwiftUI und den Previews)

Genau wie React, setzen wir React-Native schon sehr früh ein und können auf umfangreiche Erfahrungswerte zurückgreifen (unter anderem dank unserer App-Projekte für Tradity und die Kölner Haie).

‍

‍

Typescript

`cannot read ‚name‘ of undefined`

Ich denke, es gibt keinen JavaScript-Entwickler, der diesen Fehler noch nicht zu Gesicht bekommen hat.

Dank Typescript konnte dort aber etwas Abhilfe geschaffen werden. Endlich war es möglich, JavasScript zu typisieren. React bot schon sehr lange eine Möglichkeit dies zumindest auf Component-Props Ebene zu tun: PropTypes.

Dank Typescript ist es aber nun möglich, Server-Responses o.ä. mit Typen zu versehen und dadurch nicht nur die Sicherheit, sondern auch eine Erleichterung durch Autovervollständigung zu erhalten.