Preis: 9,80 €
Erhältlich ab: März 2018
kann man JavaScript noch als Trend bezeichnen, oder geht es nicht schon längst um die Trends innerhalb der JavaScript-Welt? Wir tendieren dazu, der zweiten These zuzustimmen: JavaScript ist einer der zentralen Bausteine des modernen Webs und setzt selbst Trends in der Webentwicklung. Die Gretchenfrage des Webentwicklers lautet schon lange nicht mehr, ob man mit JavaScript arbeitet, sondern welches Framework, welche Bibliothek man wählt. Das Ökosystem ist es, was Trends setzt.
Allerdings findet die Evolution der JavaScript-Welt natürlich nicht nur auf dieser Ebene statt. Auch der Sprachkern selbst wird kontinuierlich weiterentwickelt und geht mit der Zeit. Das muss JavaScript auch: Eingeführt 1995, gehört JavaScript nicht mehr zu den jüngsten Sprachen im Web und bewegt sich doch auf einem Gebiet, das einem stetigen Wandel unterlegen ist. Erinnern Sie sich noch an die Websites der frühen 2000er-Jahre? Seitdem hat sich viel im Internet getan, und JavaScript war immer mit dabei. In gewisser Weise ist JavaScript mit seinen nun 23 Jahren erwachsen geworden.
Wenn wir heute über JavaScript sprechen, muss aber auch die Frage gestellt werden, worum es eigentlich genau geht: JavaScript ist schon lange keine singuläre Sprache mehr, die einfach zu definieren wäre. Natürlich wird der Sprachkern von Ecma International entwickelt und als ECMAScript bezeichnet. Die Entscheidungen darüber, was es in den neuen Standard schafft, werden von einem technischen Komitee getroffen, das von Ecma International eingesetzt wird – diskutiert wird allerdings auf GitHub und mit der Community. In diesem Jahr haben es insgesamt acht neue Vorschläge in den Standard geschafft, darunter Verbesserungen an der Lesbarkeit von Regular Expressions. Andere Fragen, wie die nach dem Semikolon am Zeilenende von JavaScript-Code, werden immer noch heiß diskutiert. Die JavaScript-Welt ist lebendig.
Das zeigt sich auch daran, dass wir über viel mehr sprechen müssen als über ECMAScript, wenn wir JavaScript als Websprache gerecht werden wollen: TypeScript ist beispielsweise ein Superset von ECMAScript und bietet Entwicklern Optionen, die der JavaScript-Kern nicht beherrscht. Die statische Typisierung sticht hier besonders hervor. Darum haben wir dem Thema JavaScript und TypeScript eine eigene Rubrik in diesem Entwickler Magazin Spezial gewidmet.
Trends setzen darüber hinaus aber vor allem die verschiedenen Frameworks und Bibliotheken: Nachdem Angular eine Zeit lang das beliebteste Framework war, geht der Trend heute zu React und vielleicht darüber hinaus sogar bereits hin zu Vue.js. Die rasante Aufholjagd auf die beiden Spitzenreiter, die Vue.js im vergangenen Jahr begonnen hat, zeigt allerdings auch, wie schnelllebig die JavaScript-Welt im Frontend ist.
Außerdem hat JavaScript inzwischen sogar die Grenzen der klassischen Browserumgebung überschritten. Mit Electron können Desktopanwendungen mit JavaScript geschrieben werden, React Native bringt JavaScript in native mobile Apps für Smartphone und Tablet. Und das sind nur einzelne Beispiele für die vielfältigen Optionen, die das JavaScript-Ökosystem heute umfasst.
Trends und Standards, Sprachdialekte und ein großes Ökosystem: Das ist es, was wir für Sie in diesem Heft zusammengestellt haben. Und nun wünsche ich Ihnen viel Spaß dabei, die große JavaScript-Welt zu erforschen und ein bisschen besser kennenzulernen.
React ist für sich allein genommen ausreichend für einfache Webanwendungen. Wer mehr aus einem React-Projekt machen möchte, dem steht ein reiches Ökosystem zur Verfügung. Ob für das Styling von Komponenten oder das Routing: Für alles gibt es eine Bibliothek. Dieser Artikel gibt einen Überblick über die vielfältigen Optionen zur Erweiterung von React.
React fokussiert sich auf den View-Layer in Webapplikationen und wird als Basis zur Erstellung von User Interfaces mit Komponenten genutzt. Oft wird React nachgesagt, dass es alleine ausreichend sei, um Webanwendungen zu erstellen. Wie ich in meinem eigenen Buch „The Road to Learn React“ [1] zeige, kann dies wirklich so umgesetzt werden. Vor allem um React zu erlernen, ist es von Vorteil, sich nur auf React zu konzentrieren, aber auch in kleineren Anwendungen kann es vollkommen ausreichend sein, nur React zu benutzen. Wenn es aber um die Implementierung einer größeren und komplexeren Anwendung geht, braucht man doch noch ein paar weitere Bibliotheken rund um React.
Entwickler, die zuvor mit Frameworks wie Angular oder Ember gearbeitet haben, tun sich oft schwer damit, die nötigen Bibliotheken zu identifizieren, die für eine technisch ausgefeilte Webanwendung auf Basis von React notwendig sind. Wer vorher mit einem Framework gearbeitet hat, ist daran gewöhnt, dass alle Funktionen unmittelbar verfügbar sind. Daran zeigt sich, dass React einfach nur eine Bibliothek für den View-Layer ist. Demnach muss man sich selbst um alle anderen Bibliotheken kümmern. Das ist aber auch einer der zentralen Vorteile von React. Es ermöglicht eine flexible Auswahl der weiteren Bibliotheken, die man seiner Anwendung hinzufügt. Man selbst bleibt aber unabhängig von einem Framework.
React mit seinem Ökosystem ist eine Art flexibles Framework. Man selbst sucht Bibliotheken aus, die zum Kern der Anwendung hinzugefügt werden können. Der folgende Artikel stellt eine subjektive Auswahl dieser Bibliotheken in verschiedenen Themenbereichen vor, die nützlich für kleinere, aber auch komplexe React-Anwendungen sind. Natürlich muss am Ende jeder selbst seine Wahl treffen und das passende Set an Bibliotheken für seine Zwecke zusammenstellen. Die hier vorgestellte Auswahl soll vor allem Einsteigern ins React-Ökosystem einen Überblick über die verschiedenen Optionen geben.
Die Entscheidung für das richtige Starter-Projekt, auch Boilerplate-Projekt genannt, für eine React-Anwendung fällt vielen Entwicklern schwer. In der modernen Webentwicklung hört man schnell von Tools wie Babel und webpack. Etliche Boilerplate-Projekte für React stehen online zur Auswahl, und jedes davon ist auf einen bestimmten Anwendungsfall zugeschnitten und benutzt verschiedenste Konfigurationen beispielsweise für Babel und webpack. Die Auswahl reicht von minimalistischen Ansätzen bis hin zu beinahe schon überladenen Projekten. Letztere machen leider die Mehrheit der online auffindbaren Projekte aus, zu Ungunsten von Neuankömmlingen im React-Ökosystem.
Im Folgenden möchte ich auf das Boilerplate-Projekt Create React App [2] eingehen, das ein weithin akzeptierter Communitystandard ist. Es handelt sich um ein konfigurationsfreies Starter-Projekt, mit dem eine minimalistische lauffähige React-Anwendung out of the box erstellt werden kann. Dabei bleibt der Nutzer erst einmal verschont von Tools wie Babel und webpack. Auch im Nachhinein kann das zugrunde liegende Toolset über eine sogenannte eject-Funktionalität angepasst werden. Demzufolge ist Create React App das Go-To-Projekt für React-Neuankömmlinge, weil es möglich ist, sich hierbei ausschließlich auf React zu konzentrieren.
Eine ähnliche Lösung wie Create React App stellt Next.js [3] dar. Auch dabei handelt es sich um ein konfigurationsfreies Boilerplate-Projekt für React, allerdings für serverseitig gerenderte Anwendungen. Gatsby ist eine weitere Alternative und eine großartige Wahl für statische Websites (z. B. Blogs) mit React.
Wer ein individuelles Boilerplate-Projekt für den eigenen Zweck einsetzen will, sollte zuerst die eigenen Anforderungen an die Anwendung eingrenzen. Ein Boilerplate-Projekt sollte so minimalistisch wie möglich sein und nicht zu viele Aufgaben auf einmal erfüllen. Die Wahl eines Projekts, das es schon online gibt, oder das Erstellen eines eigenen Projekts sollte auf die spezifischen Anforderungen zugeschnitten sein.
Create React App
Gatsby [4] für statische Websites in React
Next.js für serverseitig gerendertes React
Bei guten React-Kenntnissen: eigene minimalistische Boilerplate erstellen
Ansonsten: Anforderungen definieren, minimalistische Lösung finden
JavaScript bringt ab ES6 unzählige eingebaute Funktionen für die Arbeit mit Arrays, Objekten, Integern und Strings mit. In React ist die Methode map() für Arrays [5] eine der am häufigsten genutzten Standardfunktionen von JavaScript. Warum? Weil in Komponenten oft eine Liste von Dingen gerendert werden muss. Und da JSX eine Mischung aus HTML und JavaScript ist, kann man JavaScript nutzen, um über diese Liste mit map() zu iterieren, um jeden einzelnen Wert als Element in JSX zurückzugeben.
const List = ({ list }) =>
<div>
{list.map(item => <div key={item.id}>{item.title}</div>)}
</div>
Falls die JavaScript-Funktionen komplexer werden sollten, bietet sich eine Utility-Bibliothek an. Persönlich würde ich dafür zwei Bibliotheken empfehlen, die exklusiv verwendet werden sollten.
Meine erste Empfehlung ist Lodash [6], der Nachfolger von Underscore und die am weitesten verbreitete Utility-Bibliothek für JavaScript. Lodash ermöglicht es, Arrays zu sortieren, zu filtern oder zu gruppieren, aber auch mehrere Funktionen miteinander zu verketten oder zusammenzustellen. Der Funktionsumfang geht weit über die angebotenen Funktionen von nativem JavaScript für Arrays und Objekte hinaus.
Mein zweiter Tipp ist Ramda [7]. Wer in die Richtung der funktionalen Programmierung (FP) in JavaScript gehen möchte, kommt nicht an dieser Utility-Bibliothek vorbei. Obwohl Lodash ein eigenes Derivat für die funktionale Programmierung besitzt (Lodash FP [8]), würde ich bei funktionaler Programmierung eher zu Ramda tendieren. In dieser Bibliothek steht das FP einfach im Vordergrund.
Wenn man eine Utility Libary zu seiner React-Applikation hinzufügen will, kann man also Lodash oder Ramda nehmen. Lodash ist dabei eine eher bodenständige Bibliothek für jeden JavaScript-Entwickler, während Ramda mit einem starken Fokus auf die funktionale Programmierung daher kommt.
JavaScript ES6 und höher
Lodash
Ramda für funktionale Programmierung
Im Themenbereich Styling existieren viele Meinungen im React-Ökosystem. Das Thema ist nicht nur dann umstritten, wenn es um die spezifischen Lösungen geht, die momentan verfügbar sind, sondern auch auf einer philosophischen Ebene für Designer und Entwickler gleichermaßen. Sollte es beispielsweise erlaubt sein, das style-Attribut eines HTML-Elements in JSX unterzubringen (Inlinestyle)? Oder sollten Styles neben Komponenten in JavaScript definiert werden (CSS in JS)? Oftmals reicht reines CSS für den Anfang in React völlig aus. Wer sein erstes Projekt mit Create React App selbst aufsetzt, arbeitet erst einmal nur mit herkömmlichen CSS und eventuell Inlinestyle.
const Headline = ({ children }) =>
<h1 className="headline" style={{ color: 'lightblue' }}>
{children}
</h1>
Für kleinere Projekte kann das bereits ausreichend sein. Wenn die Anwendung aber wächst, ist es empfehlenswert, einen Blick auf CSS Modules [9] zu werfen. Damit hat jede CSS-Datei ihren eigenen Namespace, kann direkt neben einer JavaScript-Datei mit einer Komponente definiert werden und vermeidet somit durch den Namespace, dass die Styles in andere Teile der Anwendung verbreitet werden. Der Style aus der CSS-Datei wird meist nur auf die danebenliegende Komponente in der JavaScript-Datei beschränkt. CSS Modules lassen sich außerdem gut skalieren, wenn eine Anwendung größer werden sollte.
Einen anderen Ansatz für das Styling einer React-Komponente bieten die sogenannten Styled Components an. Dieser Ansatz wird durch die Bibliothek styled-components [10] ermöglicht. Dabei werden React-Komponenten mit CSS-Styles definiert und können so einfach in Reacts JSX-Syntax verwendet werden. Dadurch erfolgt das Styling der Anwendung in den Komponenten selbst und nicht mehr separat in CSS-Dateien.
Abschließend gibt es noch eine weitere Bibliothek für das Styling in React zu nennen: Classnames [11]. Damit können CSS-Klassen in JavaScript bedingt hinzugefügt werden. Das ist mit reinem JavaScript auch möglich, ist mit der Classnames-Bibliothek aber deutlich leichter. Ein Vergleich der beiden Ansätze ist in Listing 1 und Listing 2 zu sehen. Listing 3 zeigt, dass die Classnames-Bibliothek auch perfekt in Kombination mit CSS-Klassen aus den CSS Modules funktioniert. In Kombination mit Styled Components wird diese Bibliothek eher weniger benutzt. Trotzdem ist die Classnames-Bibliothek für viele React-Einsteiger fast schon obligatorisch, wenn es um bedingtes Styling in React geht.
Listing 1: Reines JavaScript
const Box = ({ status, children }) => {
let classNames = ['box'];
if (status === 'INFO') {
classNames.push('box-info');
}
if (status === 'WARNING') {
classNames.push('box-warning');
}
if (status === 'ERROR') {
classNames.push('box-error');
}
return (
<div className={classNames.join(' ')}>
{children}
</div>
);
}
Listing 2: Classnames-Bibliothek
import cs from 'classnames';
const Box = ({ status, children }) => {
let classNames = cs('box', {
'box-info': status === 'INFO',
'box-warning': status === 'WARNING',
'box-error': status === 'ERROR',
});
return (
<div className={classNames}>
{children}
</div>
);
}
Listing 3: Classnames und CSS Modules
import cs from 'classnames';
import styles from './style.css';
const Box = ({ status, children }) => {
let classNames = cs('box', {
[styles.box_info]: status === 'INFO',
[styles.box_warning]: status === 'WARNING',
[styles.box_error]: status === 'ERROR',
});
return (
<div className={classNames}>
{children}
</div>
);
}
Reines CSS und Inlinestyles
Die fast schon obligatorische Classnames Library
CSS Modules
Styled Components
Wenn man eine komplexere React-Anwendung implementiert, wird man oftmals nicht um Requests zu Drittanbieter-APIs zur Abfrage von Daten herumkommen. Früher wurde dafür jQuery genutzt. In React sollte es allerdings möglichst vermieden werden, eine Bibliothek wie jQuery einzubinden. Heutzutage verfügen modernere Browser über das native Fetch-API [12], das es ermöglicht, asynchrone Requests im Browser auszuführen. Unter der Haube arbeitet das Fetch-API mit Promises. Ein Fetch sieht grundsätzlich wie folgt aus, beispielsweise in einer React-Lifecycle-Methode, wenn eine Komponente in ihrem Lebenszyklus gemountet wird:
componentDidMount() {
fetch(my/api/domain)
.then(response => response.json())
.then(result => {
// do success handling
// e.g. store in local state
});
}
Im Grunde ist für so ein Request zu einem Drittanbieter-API keine zusätzliche Bibliothek notwendig. Trotzdem ist das native Fetch-API nur bedingt in (modernen) Browsern verfügbar. Auch wenn man dem mit Polyfills und isomorphic-fetch [13] begegnen kann, gibt es alternativ auch JavaScript-Bibliotheken, deren einziger Zweck die Ausführung solcher asynchronen Requests ist. Eine solche Bibliothek, die ich für empfehlenswert halte, nennt sich axios [14], die statt des nativen Fetch-API verwendet werden kann.
Das native Fetch-API
axios
Irgendwann kommt man an den Punkt, an dem man Funktionalitäten aus einer Komponente gerne in anderen Komponenten wiederverwenden möchte. Um diese Funktionalitäten zu extrahieren, bieten sich Higher Order Components (HOC) an [15]. Eine HOC wird genutzt, um eine React-Komponente mit solchen extrahierten Funktionalitäten zu erweitern. Die eigentliche React-Komponente kann somit sehr leichtgewichtig ausfallen, da sie den Großteil der Funktionalitäten in eine Higher Order Component auslagert. Für diese Art von Komponenten benötigt man keine zusätzliche Bibliothek in React (Listing 4)..
Listing 4: Higher Order Components
// HOC declaration
function withLoadingSpinner(Component) {
return function EnhancedComponent({ isLoading, ...props }) {
if (!isLoading) {
return <Component { ...props } />;
}
return <LoadingSpinner />;
};
}
// Usage
const ListItemsWithLoadingIndicator = withLoadingSpinner(ListItems);
<ListItemsWithLoadingIndicator
isLoading={props.isLoading}
list={props.list}
/>
Die Bibliothek Recompose [16] bringt einige Higher Order Components für typische Anwendungsfälle von HOCs in React mit. Bevor also eigene Higher Order Components implementiert werden, sollte man einen Blick auf die Bibliothek werfen, ob der Anwendungszweck, für den man eine Higher Order Component nutzen möchte, nicht bereits durch die Recompose-Bibliothek abgedeckt wird.
Recompose für Komponenten höherer Ordnung für Utilities
Recompose oder eine Utility Library (Lodash, Ramda) für Compose
React verfügt selbst über ein eigenes Type Checking. Mit PropTypes [17] kann man selbst Properties für React Components definieren (Listing 5).
Listing 5: PropTypes
import PropTypes from 'prop-types';
const List = ({ list }) =>
<div>
{list.map(item => <div key={item.id}>{item.title}</div>)}
</div>
List.propTypes = {
list: PropTypes.array.isRequired,
};
Wenn ein falscher Typ an eine Komponente übergeben wird, wird bei Ausführung der Anwendung eine Fehlermeldung ausgegeben. Diese Art des Type Checkings sollte aber nur in kleineren Anwendungen genutzt werden.
In größeren React-Anwendungen kann es sinnvoll sein, mit komplexerem Type Checking zu arbeiten, beispielsweise mit Flow [18] oder TypeScript [19]. Damit können Fehler bereits während der Entwicklung ausgegeben werden, ohne dass die Anwendung gestartet werden muss. Somit können vermeidbare Bugs frühzeitig gefunden werden. Auf diese Weise trägt das Type Checking dazu bei, die Entwicklungserfahrung angenehmer zu gestalten und Bugs zu vermeiden. Flow wurde von Facebook entwickelt und fühlt sich im React-Ökosystem natürlicher an als TypeScript. Darum empfehle ich, eher Flow als TypeScript in React zu benutzen.
PropTypes
Flow (oder TypeScript)
Es stehen grundsätzlich drei Optionen für die Codeformatierung in React zur Auswahl, die in etwa dem entsprechen, was auch in anderen Frameworks wie Angular und Vue.js möglich ist.
Die erste Option ist die Verwendung eines populären Styleguides. Dieser kann verwendet werden, um Richtlinien für Codeformatierungen, z. B. bei der stilistischen Formatierung von React-Komponenten, auf den eigenen Sourcecode zu übertragen. Ein beliebter Styleguide für React wurde beispielsweise von Airbnb veröffentlicht [20]. Auch wenn man einen Styleguide nicht zu 100 Prozent befolgt, ist es sinnvoll, sich mit ein paar Styleguides zu beschäftigen, um die Grundlagen der Codeformatierung in React nachvollziehen zu können.
Ein Styleguide ohne den Zwang, ihn auch wirklich zu befolgen, bringt bei der Arbeit in Teams recht wenig. Der zweite Ansatz besteht in der Nutzung eines Linters, beispielsweise ESLint in JavaScript. Ein Linter kann für das eigene Projekt konfiguriert werden [21], um beispielweise Styleguides zu folgen. Wird eine Richtlinie des Styleguides im Projekt nicht beachtet, wird auf der Konsole eine Warnung ausgegeben. Somit muss das gesamte Team eines Projekts denselben Richtlinien folgen, um die Formatierung des Sourcecodes zu vereinheitlichen.
Die dritte und beliebteste Option ist die Verwendung eines automatischen Formatters. Prettier [22] ist ein solcher Formatter, der den Code nach internen Regeln formatiert. Diese Regeln können teilweise konfiguriert werden, folgen aber dennoch einem eigenen Standard. Prettier kann in einen Editor oder eine IDE integriert werden und formatiert den Code immer dann, wenn man beispielweise eine Datei speichert oder Dateien in eine Versionsverwaltung wie Git eincheckt [23]. Anfangs entspricht die Formatierung nicht immer dem eigenen Geschmack, dafür muss man sich aber immerhin nicht mehr um die Codeformatierung in der eigenen Codebasis oder der des Teams kümmern.
Einen beliebten Styleguide lesen
Prettier
In der Webentwicklung möchte man viele Komponenten nicht immer wieder von Grund auf neu implementieren, wenn man gerade an einer neuen Anwendung arbeitet. Komponenten wie Datepicker, Drop-down-Menüs, Tabellen oder Navigationselemente sollten irgendwo vorgefertigt vorliegen. Dafür gibt es UI-Bibliotheken, die gut mit React kombinierbar sind. Persönlich empfinde ich Semantic UI [24] und Material-UI [25] als gute Optionen, die ich mehrfach in eigenen Projekten eingesetzt habe. Wenn man sich an eine Bibliothek gewöhnt hat, will man nicht ständig auf ein neues Pferd setzen.
Semantic UI
React bringt zum Glück sein eigenes lokales State Management in Komponenten mit, sodass es für den Anfang ausreicht, den Umgang mit React zu erlernen. Die Grundlagen lernt man schnell, indem man this.state und this.setState() für das lokale State Management nutzt. Viele Anfänger machen aber den Fehler, React direkt mit einer Bibliothek wie Redux zu verwenden [26]. Das sollte man für den Einstieg eher sein lassen.
Was aber tun, wenn die ersten Probleme mit Reacts State Management auftreten, weil die Anwendung größer wird? Dafür gibt es zwei mögliche Lösungen: Redux und MobX. Beide haben ihre Vor- und Nachteile. Unter [27] gibt es mehr Informationen zu beiden Tools, mit denen man zu einer fundierteren Entscheidung gelangen kann.
Redux ist sehr beliebt und verfolgt gleichzeitig einen recht innovativen Ansatz mit funktionaler Programmierung. Die Bibliothek ist so populär geworden, dass sie schon ihr eigenes Ökosystem an Bibliotheken mitbringt [28]. Wenn man Redux mit React verwendet, stößt man so gut wie zwangsläufig auf die Bibliothek React Redux [29]. Dabei handelt es sich um die offizielle Bibliothek, um den View-Layer (React) mit dem State-Layer (Redux) zu verbinden. Auch für die alternative State-Management-Bibliothek MobX gibt es eine solche Bibliothek [30], um beide Welten miteinander zu verbinden. Allen, die den Umgang mit Redux lernen wollen, empfehle ich das Buch „Taming the State in React“ [31].
Das lokale State Management von React
Redux oder MobX
Nur, wenn man bereits mit dem lokalen State vertraut ist
Nur, wenn es wirklich notwendig ist
Routing wird häufig schon zu einem frühen Zeitpunkt in der Entwicklung von React-Anwendungen eingeführt. Schlussendlich wird der von React realisierte View-Layer zumeist in Single Page Applications verwendet. Routing ist darum ein zentraler Bestandteil der Anwendungen, um mittels URLs durch die Applikation zu navigieren.
Bevor man aber einen komplexen Router in die Anwendung aufnimmt, während man eigentlich gerade erst lernt, mit React zu arbeiten, sollte man sich zuerst das bedingte Rendering von React ansehen [32] und es damit probieren. Dabei handelt es sich nicht um einen vollständigen Ersatz für ein richtiges Routing; für kleine Anwendungen reicht es aber doch oft, Komponenten darüber konditional auszutauschen. Damit können zumindest verschiedene States auf den View-Layer gerendert werden, der URL wird aber nicht ausgetauscht.
Für die Implementierung eines richtigen Routings stehen wieder verschiedene Lösungen für React zur Wahl. Die beliebteste Option stellt der React Router [33] dar, der gut in Kombination mit externen State-Management-Bibliotheken funktioniert, beispielsweise Redux oder MobX.
Bedingtes Rendering in React
React Router
In komplexer werdenden Anwendungen kann die Anforderung aufkommen, Authentifizierung und Authentisierung zu ermöglichen. Dazu gehören beispielsweise Funktionalitäten für die Registrierung, das Log-in und das Log-out von Nutzern. Authentifizierungsmechanismen gehen aber oft noch weit darüber hinaus – man muss ja auch Passwörter zurücksetzen oder aktualisieren können und die Nutzerdaten in einer Datenbank verwalten. Deswegen habe ich mich mit diesem Thema intensiv befasst und ein umfassendes Tutorial dafür geschrieben, das unter [34] zu finden ist. Im Tutorial wird Firebase für die Authentifizierung und die Speicherung von Nutzerdaten in einer Echtzeitdatenbank verwendet. Weitere Alternativen für die Authentifizierung sind Auth0 [35] und Passport [36].
Firebase
Am Ende kann man das React-Ökosystem als eine Art Framework für React ansehen. Allerdings ist es ein sehr flexibles Ökosystem: Man entscheidet selbst, welche Bibliotheken man nutzen möchte und kann klein anfangen, indem man nur React nutzt. Nach und nach können weitere Bibliotheken hinzugefügt werden, die man zur Lösung von spezifischen Problemen benötigt. Die einzelnen Bausteine, die einer React-Applikation hinzugefügt werden, können somit flexibel und eigenhändig skaliert werden. Oder aber man belässt die Applikation leichtgewichtig, weil sie auch nicht allzu komplex ist, und bleibt einfach bei einem einfachen React. Darum hier nochmal eine zusammenfassende und abschließende Liste von Bibliotheken, die man zur Ergänzung in React-Anwendungen hinzunehmen kann (Kasten: „Empfehlungen nach Projektgröße“). Die Liste ist zum weiteren Verständnis in Projektgrößen unterteilt. Natürlich handelt es sich hierbei um eine persönliche Auswahl, deswegen bin ich gespannt, eure Meinung dazu zu hören. Das „ideale“ Set-up für React ist natürlich eine Frage des eigenen Geschmacks und der eigenen Notwendigkeiten und jedem Entwickler selbst überlassen. Ein objektiv perfektes Set-up gibt es nicht.
Boilerplate: Create React App
Utility-Bibliothek: JavaScript ES6 und höher
Styling: pures CSS und Inlinestyle
Asynchrone Requests: Fetch
Higher Order Components: optional
Formatierung: keine
Type Checking: keins oder PropTypes
State Management: lokale States
Routing: keins oder bedingtes Rendering
Authentifizierung: Firebase
Datenbank: Firebase
UI-Komponenten: keine
Boilerplate: Create React App mit Eject
Utility-Bibliothek: JavaScript ES6 plus Lodash oder Ramda
Styling: CSS Modules oder Styled Components
Asynchrone Requests: Fetch oder Axios
Higher Order Components: möglich plus optional Recompose
Formatierung: Prettier
Type Checking: keins oder Flow
State Management: lokale States und in Ausnahmefällen Redux
Routing: React Router
Authentifizierung: Firebase
Datenbank: Firebase
UI-Komponenten: keine oder Semantic UI
Boilerplate: Create React App mit Eject oder eigenes Boilerplate-Projekt
Utility-Bibliothek: JavaScript ES6 plus Lodash oder Ramda
Styling: CSS Modules oder Styled Components
Asynchrone Requests: Axios
Higher Order Components: möglich plus optional Recompose
Formatierung: Prettier
Type Checking: Flow
State Management: lokaler State und Redux oder MobX
Routing: React Router
Authentifizierung: Lösung mit eigenem Express-/hapi-/Koa-Node. js-Server mit Passport
Datenbank: Lösung mit eigenem Express-/hapi-/Koa-Node.js-Server mit einer SQL- oder NoSQL-Datenbank
UI-Komponente: Semantic UI oder eigene Implementierung von UI-Komponenten
Seit 2017 unterstützt Robin Wieruch als Consultant Unternehmen und ihre Teams bei der Implementierung von komplexen Webapplikationen und erleichtert ihnen das Erlernen von Webtechnologien. Online schreibt er regelmäßig auf seiner Webseite und ebnet dort Lesern den Weg zu JavaScript, React und Co.
[1] Wieruch, Robin: „The Road to learn React“: https://www.robinwieruch.de/the-road-to-learn-react/
[2] Create React App: https://github.com/facebook/create-react-app
[3] Next.js: https://github.com/zeit/next.js/
[4] Gatsby: https://github.com/gatsbyjs/gatsby
[5] Array.prototype.map(): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map
[6] Lodash: https://lodash.com/
[7] Ramda: http://ramdajs.com/
[8] Lodash FP Guide: https://github.com/lodash/lodash/wiki/FP-Guide
[9] CSS Modules: https://github.com/css-modules/css-modules
[10] styled-components: https://github.com/styled-components/styled-components
[11] Classnames: https://github.com/JedWatson/classnames
[12] Fetch-API: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
[13] isomorphic-fetch: https://github.com/matthew-andrews/isomorphic-fetch
[14] axios: https://github.com/axios/axios
[15] A gentle Introduction to React‘s Higher Order Components: https://www.robinwieruch.de/gentle-introduction-higher-order-components/
[16] Recompose: https://github.com/acdlite/recompose
[17] PropTypes: https://reactjs.org/docs/typechecking-with-proptypes.html
[18] Flow: https://flow.org/
[19] TypeScript: https://www.typescriptlang.org/
[20] React Styleguide von Airbnb: https://github.com/airbnb/javascript/tree/master/react
[21] Wieruch, Robin: „React Code Style with ESLint + Babel + Webpack“: https://www.robinwieruch.de/react-eslint-webpack-babel/
[22] Prettier: https://github.com/prettier/prettier
[23] GitHub and Git Essentials: https://www.robinwieruch.de/git-essential-commands/
[24] Semantic UI React: https://react.semantic-ui.com/introduction
[25] Material-UI: http://www.material-ui.com/#/
[26] 8 things to learn in React before using Redux: https://www.robinwieruch.de/learn-react-before-using-redux/
[27] Redux or MobX: An attempt to dissolve the Confusion: https://www.robinwieruch.de/redux-mobx-confusion/
[28] Redux Ecosystem Links: https://github.com/markerikson/redux-ecosystem-links
[29] React Redux: https://github.com/reactjs/react-redux
[30] mobx-react: https://github.com/mobxjs/mobx-react
[31] The Road to React: https://roadtoreact.com/
[32] All the Conditional Renderings in React: https://www.robinwieruch.de/conditional-rendering-react/
[33] React Router: https://github.com/ReactTraining/react-router
[34] A Complete Firebase in React Authentication Tutorial [2018]: https://www.robinwieruch.de/complete-firebase-authentication-react-tutorial/
[35] Auth0: https://auth0.com/
[36] Passport: http://www.passportjs.org/