BRICKMAKERS Starter Template für Frontends mit React

Mit React — Redux — Redux Saga

Das komplette Starter Set gibt es hier:

Bei uns in der Firma werden fast alle neuen Projekte mit Hilfe von React umgesetzt. Und auch firmenübergreifend lässt sich dieser Trend erkennen.

Unserer Meinung nach werden im Jahr 2018 noch mehr Projekte mit React gestartet als im letzten Jahr. Inzwischen sollte auch jeder Frontend-Entwickler über das Flux-Pattern Bescheid wissen, die meisten davon haben Redux oder MobX in mindestens einem größeren Projekt verwendet.

Um in der gesamten Firma ein einheitliches Projektsetup einzuführen, haben wir beschlossen ein Boilerplate / Template für neue Projekte zu erstellen. Mit dem Grundgerüst sind wir sehr zufrieden und deshalb wollen wir es euch allen zur Verfügung stellen.

Natürlich gibt es zahlreiche andere Templates oder Tools, die das Projektsetup leichter machen. Meiner Meinung kommt man aber bei vielen Code-Generatoren, wie bspw. create-react-app schnell an einen Punkt, an dem einem die Konfigurationsoptionen nicht mehr ausreichen oder man sich nicht so sehr an die Vorgaben halten möchte. Zumindest ist uns das bei einigen mittelgroßen Projekten passiert. Dann benötigt man eine eigene Webpack Konfiguration, etc.

Unser Starter Paket:

Also wollen wir einmal einen Blick in unser Repository werfen und die verwendeten Pakete kurz vorstellen.

Generell

Webpack
Eslint Loader
Tailwind.js

React Ecosystem

React 16
Redux
Redux Saga

Pakete und Erklärung (1) : Generell

Webpack

In unserem Projekt gibt es 4 Webpack Konfigurationsdateien.

Webpack.common.js
Webpack.dev.js
Webpack.dev-local.js
Webpack.prod.js

webpack.common.js

Alle Umgebungen greifen auf die Webpack.common.js zu. Hier werden alle Loader definiert, sowie generelle Plugins die in allen anderen Umgebungen auch verwendet werden. Alle tatsächlichen Umgebungen sind in einzelnen Dateien konfiguriert und werden mit Hilfe von webpack-merge zusammengeführt.

webpack.common.js

webpack.dev.js und webpack.dev-local.js

Auch die Webpack Konfiguration für den Entwickler greift auf unsere webpack.common zu. Zusätzlich wird aber hier noch der devServer eingestellt, sowie die APIURL abgeändert.

Für das reine Entwickeln des Frontends verwenden wir meistens eine APIURL die mit dem Backend der Staging / Test Umgebung verknüpft ist. So kann der Entwickler sich das parallele Ausführen von dem Backend häufig sparen.

webpack.dev.js

const webpack = require('webpack');
const Merge = require('webpack-merge');
const CommonConfig = require('./webpack.common.js');

module.exports = function(env) {
return Merge(CommonConfig(env), {
devtool: 'inline-source-map',
devServer: {
historyApiFallback: true,
host: '0.0.0.0',
disableHostCheck: true
},
plugins: [
new webpack.DefinePlugin({
API_TARGET: JSON.stringify(
'https://insert-your-online-api-here.net/'
),
})
]
});
};

Wir haben zusätzlich noch eine Konfiguration erstellt für das lokale Entwickeln, falls man neue Backend Funktionen entwickelt. Hier wird lediglich die APIURL auf die localhost Adresse geändert.

Eslint-loader

Wir entwickeln alle unsere Projekte testgetrieben (TDD: test-driven-development). Deshalb finden wir nicht nur Refactoring schön, sondern auch Code-Formatierung an sich.

Hier für haben wir im letzten Jahr üblicherweise die Linter auf allen Entwicklungssystemen installiert und jeder hat seine Konfigurationen selbst verwaltet. Dadurch haben einige sehr häufig die Formatierungen angepasst, andere jedoch selten. Insgesamt war unsere Codebasis also ungefähr zu 80% gut formatiert. Doch auch unter den Entwicklern gab es unterschiedliche Vorlieben und so wurden einige Dateien auch häufig in andere Formatierungsstile umformatiert. Das erschwert das Code-Review deutlich, wenn man nicht mehr die Änderungen Zeile für Zeile durchgehen kann, sondern nur die komplette Datei als Änderung sieht.

Durch die Konfiguration des Eslint Loaders als direkten Schritt in der Webpack Konfiguration lösen wir also mehrere Probleme auf einmal:

Codeformatierungs „Fehler“ werden direkt behoben (an Hand einmalig definierter Regeln, die für das komplette Projekt gelten)
Jeder Entwickler kann direkt auf die Linter zugreifen und muss nichts zusätzlich installieren.
Netter Nebeneffekt: Man kann sich auch nicht so einfach entscheiden, den Linter zu deaktivieren.
Nochmal im Klartext: Alle Entwickler arbeiten also mit den gleichen Formatierungen und erzeugen einheitlichen Code und das sogar ohne die Formatierung selbst vornehmen zu müssen !

webpack.common.js

module: {
loaders: [
{
test: /\.js$/,
enforce: 'pre',
exclude: /node_modules/,
use: [
{
loader: 'eslint-loader',
options: {
emitWarning: true,
fix: true
}
}
]
},

[...]

Tailwind.js

Tailwind.js ist ein minimalistisches CSS Framework, was nicht nur für schnelle Prototypen gut geeignet ist, sondern auch sehr frei konfigurierbar ist und somit ein einheitliches Schema für die Verwendung innerhalb der Komponenten vorgibt. Wenn man sich komplett darauf einlässt, benötigt man keine .css Dateien mehr.

Also meine Empfehlung ist definitiv: Schaut euch tailwind mal genauer an :

tailwindcss.com

Pakete und Erklärung (2) : React Ecosystem

Um auch größere Anwendungen zu realisieren sollte es an Redux nicht fehlen. Wir haben auch selbst die Erfahrung gemacht, wie und an welchen Stellen Redux einfach enorm hilfreich ist. Unsere erste React Native Anwendung haben wir zum Beispiel noch ohne Redux umgesetzt, da nur wenige unterschiedliche Datensätze verwendet werden. Jeder Screen war dort ziemlich eigenständig und hatte keinen Einfluss auf den Rest der Anwendung. Insgesamt war die Anwendung auch ein kleines und kurzes Projekt, aber gegen Ende haben wir Redux sehr vermisst. :(

Zusätzlich setzen wir in fast allen Projekten inzwischen Redux-Saga ein. Die sequentielle Durchführung der in Saga verwendeten Function-Generators eignet sich sehr gut, um diese auch mit Tests abzudecken.

Allgemein gefällt uns der Stil sehr gut, dass die Sagas die Kernlogik und die Kommunikation zum Backend vollständig abdecken.

Außerdem kann man mit Hilfe des “Navigation”-Patterns in Redux-Saga sich sogar das Erstellen einiger Actions sparen, da man einfach die komplette Saga ausführt, wenn auf eine Route mit Saga navigiert wird.

Nun wünschen wir euch viel Spaß beim Verwenden unseres Boilerplates. Falls euch der verwendete Stack gut gefällt oder ihr Verbesserungsvorschläge für uns habt, dann schreibt gerne einen Kommentar. Auch über Pull Requests, etc. würden wir uns freuen.

Wir überlegen zur Zeit auch, ob wir das Boilerplate Projekt mit Hilfe von yeoman in ein Generator-Tool wie beispielsweise create-react-app umwandeln sollen — hättet ihr daran Interesse? Somit wären redux-saga, tailwind komplett optional und könnten beim Erstellen mit Hilfe des Skripts aus dem Startprojekt entfernt werden.