Update article titles for clarity and localization

tidusIO · tidusIO · commit 5026244e3f0d · 2026-03-05T17:56:25.000+07:00
- Revised the title of the React Native tutorial to better reflect the content and improve accessibility for German-speaking audiences.
- Adjusted the title of the React Redux Toolkit article to enhance clarity and ensure consistency in naming conventions.
- These changes aim to improve user engagement and provide a more localized experience.
diff --git a/src/content/posts/de/2021-02-01-react-native-tutorial-konrad/index.md b/src/content/posts/de/2021-02-01-react-native-tutorial-konrad/index.md
@@ -1,5 +1,5 @@
 ---
-title: "Reihe: React Native (Schritt für Schritt) - Umgang mit Typescript und Linting"
+title: "Reihe: React Native: TypeScript und Linting einrichten"
 description: "Im ersten Teil unserer React Native (Schritt für Schritt)-Reihe, gucken wir uns an, wie wir ein neues Projekt mit Expo und Typescript starten und wie wir unseren Linter konfigurieren. Außerdem reden wir über das „Wie“ und „Warum.“ Schnapp dir einen Kaffee, lehn dich zurück und mach dich bereit für eine faszinierende Reise."
 author: "Konrad Abe (AllBitsEqual)"
 published_at: 2021-02-01T10:00:00.000Z
@@ -9,35 +9,37 @@ categories: "react-native typescript linting expo best-practices series"
 series: "React Native (Step by Step)"
 ---
 
-**Im ersten Teil unserer *React Native (Schritt für Schritt)*-Reihe geht es um den Umgang mit Typescript und Linting. Wir gucken uns an, wie wir ein neues Projekt mit Expo und Typescript starten und wie wir unseren Linter konfigurieren. Außerdem reden wir über das „Wie“ und „Warum.“ Schnapp dir einen Kaffee, lehn dich zurück und mach dich bereit für eine faszinierende Reise.**
+**Im ersten Teil unserer _React Native (Schritt für Schritt)_-Reihe geht es um den Umgang mit Typescript und Linting. Wir gucken uns an, wie wir ein neues Projekt mit Expo und Typescript starten und wie wir unseren Linter konfigurieren. Außerdem reden wir über das „Wie“ und „Warum.“ Schnapp dir einen Kaffee, lehn dich zurück und mach dich bereit für eine faszinierende Reise.**
 
 _Wie immer findest du den fertigen Code am Ende des Artikels auf GitHub verlinkt._
 
 **Reihe: React Native (Schritt für Schritt)**
+
 1. => **du bist hier** <=
 2. [React Redux + Toolkit mit Typescript](https://allbitsequal.medium.com/series-react-native-step-by-step-react-redux-toolkit-with-typescript-4818504bba13){:rel="noopener noreferrer nofollow"}
 
 ![React Native mit TypeScript und Linting – Tutorial Teil 1](./intro.jpeg)
 
 ## Typescript - WARUM?
+
 Es gibt viele verschiedene Meinungen zum Thema Typescript. Die eingefleischten Fans schwören darauf, dass ihr Code dank Typescript weniger fehlerhaft, stabiler, leichter zu handhaben und einfacher zu erweitern, besser zu teilen und geeigneter für die Zusammenarbeit ist. Auf der anderen Seite gibt es Menschen, die Typescript als störend empfinden, weil es viel unnötigen Overhead und in einigen Fällen sogar Duplizierungen verursache, während Fehler zur Runtime nicht behoben werden würden.
 
 Ich werde hier jetzt keine umfassende Diskussion über die Pros und Kontras von Typescript starten. Ich habe mich nämlich aus vielen verschiedenen Gründen dazu entschieden, in meinen privaten Projekten mit Typescript zu arbeiten.
 
-* Ich arbeite in meinem 9-to-5 Job regelmäßig mit Typescript
-* Mir gefallen die zusätzlichen Informationen, die meine IDE aus dem strong typing Code ziehen kann
-* Viele meiner wiederverwendbaren Code Bits werden irgendwann in getrennten Repositories abgelegt und via NPM verteilt
+- Ich arbeite in meinem 9-to-5 Job regelmäßig mit Typescript
+- Mir gefallen die zusätzlichen Informationen, die meine IDE aus dem strong typing Code ziehen kann
+- Viele meiner wiederverwendbaren Code Bits werden irgendwann in getrennten Repositories abgelegt und via NPM verteilt
 
 Ich habe auch immer wieder meine „Duh“-Momente, wenn ich auf Probleme stoße, die mein Compiler/Linter nicht mag, weil ich zu vage war oder einfach gar nichts typisiert habe, weil es mich während des Schreibens gestört hat oder mir zu komplex vorkam. Ich habe mir deshalb eine Routine geschaffen, die mir erlaubt, etwas Bestehendes zu `// @ts-ignorieren` und dann meine Veränderungen zu überprüfen, bevor ich sie commite. Dadurch denke ich immer zwei Mal darüber nach, ob das Stück Code, das ich in mein Repository aufnehmen will, nicht doch noch ungeprüft ist.
 
-Es gibt Momente, in denen du dir vielleicht darüber Gedanken machst, WARUM der Typescript Compiler einen bestimmten Code nicht zulassen oder einen Typ akzeptieren möchte, der eigentlich ok aussieht, und ich bin zu der Erkenntnis gekommen, dass ich in den meisten Fällen etwas getan hätte, dass in der Zukunft für Probleme gesorgt haben KÖNNTE.  *Ja klar, ich als Entwickler weiß ganz genau, dass ich eine Funktion zu einem Zeitpunkt, an dem meine Props noch nicht definiert sind, niemals gecallt hätte...oder hätte ich das doch gemacht?* Das Hinzufügen von Null Checks (und anderen Schutzmaßnahmen) ist mittlerweile eine Angewohnheit geworden, mit der ich gut leben kann. Ich habe genug Situationen in Projekten miterlebt, bei denen etwas kaputt geht, weil aus unvorhergesehenen Gründen die Antwort des Servers leer war oder einen fehlenden oder falschen Typ hatte. Es war nicht unser Code, der falsch war, sondern das blinde Vertrauen in die API-contracts und der fehlende Doppel-Check an beiden Enden. Dadurch können unerwartete Dinge passieren, die manchmal zu unschönen und nur schwer zu findenden Fehlern führen.
+Es gibt Momente, in denen du dir vielleicht darüber Gedanken machst, WARUM der Typescript Compiler einen bestimmten Code nicht zulassen oder einen Typ akzeptieren möchte, der eigentlich ok aussieht, und ich bin zu der Erkenntnis gekommen, dass ich in den meisten Fällen etwas getan hätte, dass in der Zukunft für Probleme gesorgt haben KÖNNTE. _Ja klar, ich als Entwickler weiß ganz genau, dass ich eine Funktion zu einem Zeitpunkt, an dem meine Props noch nicht definiert sind, niemals gecallt hätte...oder hätte ich das doch gemacht?_ Das Hinzufügen von Null Checks (und anderen Schutzmaßnahmen) ist mittlerweile eine Angewohnheit geworden, mit der ich gut leben kann. Ich habe genug Situationen in Projekten miterlebt, bei denen etwas kaputt geht, weil aus unvorhergesehenen Gründen die Antwort des Servers leer war oder einen fehlenden oder falschen Typ hatte. Es war nicht unser Code, der falsch war, sondern das blinde Vertrauen in die API-contracts und der fehlende Doppel-Check an beiden Enden. Dadurch können unerwartete Dinge passieren, die manchmal zu unschönen und nur schwer zu findenden Fehlern führen.
 
 **Kurzfassung:** Ich habe gelernt, mir keine Sorgen mehr zu machen und liebe den Compiler. Ich habe viel gelernt, indem ich versucht habe zu verstehen, WAS Typescript mir sagen will und ich glaube, das hat mich zu einem besseren Programmierer gemacht, der aber trotzdem nicht erwartet, dass der Typescript Compiler immer alle Fehler verhindert.
 
-
-
 ## Typescript - WIE?
+
 ### Los geht's mit React Native und Typescript
+
 Ein neues Projekt zu starten könnte gar nicht einfacher sein. Wie schon in früheren Projekten, starten wir wieder mit Expo und bleiben im „managed workflow“, um die Dinge schön einfach zu halten.
 
 Ich gehe davon aus, dass du bereits mit NPM und GitHub gearbeitet hast und die Basics verstehst. Um mit React Native in EXPO loszulegen, musst du das Befehlszeilentool expo-cli installieren. Es wird emfpohlen, dass Tool global zu installieren und die -g flag zu verwenden.
@@ -59,14 +61,14 @@ Es kann einen Moment dauern, bis die expo-cli alle dependencies von npm herunter
 
 Das war's, du hast es geschafft. Du hast erfolgreich ein React Native-Projekt über Expo gestartet und konfiguriert, das mit Typescript ausgeführt wird.
 
-
 ### GitHub - synchronisiere deinen Fortschritt
+
 Es mag sich vielleicht so anfühlen, als hätten wir bis hier noch nicht viel geschafft. Ich empfehle dir trotzdem sehr, deine bisherige Arbeit mit einem versionierten Repository-Service wie GitHub oder GitLab zu synchronisieren. Ich persönlich nutze GitLab bei der Arbeit und GitHub für open source und private Projekte.
 
 [Dieser Artikel auf docs.github.com](https://docs.github.com/en/free-pro-team@latest/github/importing-your-projects-to-github/adding-an-existing-project-to-github-using-the-command-line) zeigt den gesamten Prozess auf sehr simple Art und Weise und macht es leicht, den Erklärungen zu folgen.
 
-
 ### Hat es funktioniert?
+
 Wenn du auf Nummer sicher gehen willst, dass bisher alles so funktioniert, wie es soll, dann gib einfach die folgende Zeile in dein Befehlszeilen-Tool ein, während du im root Verzeichnis des Projektes bist. Nun sollte sich die folgende Seite in deinem Standard-Browser öffnen. Um die Mobile-App zu überprüfen, kannst du einen Emulator im linken Menü starten. Für Mac User mit Xcode sollte der iOS Simulator am besten funktionieren.
 
 ```bash
@@ -77,13 +79,12 @@ Expo Web Interface
 
 ![Expo Web Interface nach npm start – Projekt im Browser geöffnet](./webinterface.png)
 
-
-
 ## Typescript - Zusätzliches Setup
-Natürlich möchtest du dein Projekt jetzt noch ein bisschen individualisieren. Das basic setup ist schon ganz nett, aber vielleicht können wir ja noch ein paar sinnvolle Presets importieren, ein paar weitere Regeln zu unserem Linting hinzufügen und eine Editor-Konfigurationsdatei einfügen.
 
+Natürlich möchtest du dein Projekt jetzt noch ein bisschen individualisieren. Das basic setup ist schon ganz nett, aber vielleicht können wir ja noch ein paar sinnvolle Presets importieren, ein paar weitere Regeln zu unserem Linting hinzufügen und eine Editor-Konfigurationsdatei einfügen.
 
 ### Editor Config
+
 Das ist in der Regel das erste, was ich aus meinen anderen Projekten herauskopiere und das die Arbeit in den meisten IDEs sehr viel einfacher macht. Eine `.editorconfig` Datei am Root Level deines Projektordners kann von den meisten IDEs standardmäßig gelesen werden. Andere Konfigurationsdateien können mit der Installation eines kleinen Plugins lesbar gemacht werden. Die IDE hilft dir dann automatisch mit den richtigen indentations, markiert die maximale Zeilenlänge und vieles mehr.
 
 [Geh auf diese Seite](https://editorconfig.org/), wenn du mehr erfahren möchtest oder deine eigene IDE auf Plugins prüfen willst. Lass dich dabei vom 90er Jahre Comic-Stil der Webseite nicht abschrecken, der Inhalt ist aktuell.
@@ -112,45 +113,47 @@ trim_trailing_whitespace = false
 ```
 
 ### Linting und Prettier
+
 Um mit dem linting anzufangen, müssen wir eslint und ein paar weitere Presets installieren, die wir für unser development nutzen werden.
 Wir werden außerdem Prettier benutzen, um die einfachereren Formatierungsprozesse automatisch reparieren zu lassen. Somit müssen wir nicht alle Einrückungen und Semikolons aus kopierten Code-Schnipseln aus dem Web anpassen.
 
 #### eslint
+
 Wir werden das Airbnb ESLint setup verwenden, für das mehrere packages notwendig sind. Glücklicherweise gibt es eslint-config-airbnb. Du musst nur das hier ausführen:
 
 ```bash
 npx install-peerdeps --dev eslint-config-airbnb
 ```
 
 Damit installierst du alle folgenden packages in deine projects dev dependencies:
-+ eslint@7.2.0
-+ eslint-config-airbnb@18.2.1
-+ eslint-plugin-react@7.22.0
-+ eslint-plugin-import@2.22.1
-+ eslint-plugin-react-hooks@4.0.0
-+ eslint-plugin-jsx-a11y@6.4.1
+
+- eslint@7.2.0
+- eslint-config-airbnb@18.2.1
+- eslint-plugin-react@7.22.0
+- eslint-plugin-import@2.22.1
+- eslint-plugin-react-hooks@4.0.0
+- eslint-plugin-jsx-a11y@6.4.1
 
 #### linting typescript
+
 Um mit Typescript zu arbeiten, müssen wir die libraries installieren, die uns erlauben, auch Typescript-Code zu linten.
 
 ```bash
 npm i --save-dev @typescript-eslint/parser @typescript-eslint/eslint-plugin
 ```
 
 #### prettier linting
+
 Die Installation von Prettier ist so einfach wie die von Typescript. Wir brauchen eine config und ein Plugin.
 
 ```bash
 npm i --save-dev prettier eslint-config-prettier eslint-plugin-prettier
 ```
 
-
 ### Konfiguration
 
-
 Um dich durch die Basics zu führen, ist eslint der eigentliche Linter, den wir verwenden werden. Um den Linter um zusätzliche Funktionen zu erweitern, benutzen wir außerdem den eslint Plugin Import. Der Typescript-Parser wird benötigt, um unseren Typescript Code zu analysieren. Somit kann eslint seinen Job machen und prettier erlaubt uns dadurch, gemäß unserer vordefinierten Regeln, einige Codeprobleme automatisch zu reparieren und zu verändern.
 
-
 Um ein Basis-Setup zu bekommen, kannst du einfach eslint installieren und `eslint --init` ausführen, um einen guided init Prozess zu starten. Wir werden diesen Vorgang aber selber machen und fügen unsere eigene .eslintrc config Datei zum root level des Projekts hinzu.
 
 Lass uns einen Blick auf die fertige config Datei werfen.
@@ -193,43 +196,46 @@ Lass uns einen Blick auf die fertige config Datei werfen.
         "endOfLine": "auto"
       }
     ],
-    "react/jsx-filename-extension": [1, {
-      "extensions": [
-        ".ts",
-        ".tsx"
-      ]
-    }],
+    "react/jsx-filename-extension": [
+      1,
+      {
+        "extensions": [".ts", ".tsx"]
+      }
+    ],
     "react/jsx-one-expression-per-line": "warn",
     "react/prop-types": 0,
     "react/require-default-props": 0,
     "react/style-prop-object": 0,
     "semi": ["error", "never"],
-    "no-plusplus": ["error", {"allowForLoopAfterthoughts": true}],
+    "no-plusplus": ["error", { "allowForLoopAfterthoughts": true }],
     "no-shadow": "off",
     "no-use-before-define": "off",
     "@typescript-eslint/ban-ts-comment": 0,
     "@typescript-eslint/explicit-function-return-type": 0,
     "@typescript-eslint/explicit-member-accessibility": 0,
     "@typescript-eslint/no-shadow": ["error"],
-    "@typescript-eslint/no-use-before-define": ["error", {
-      "functions": true,
-      "classes": true,
-      "variables": false
-    }],
+    "@typescript-eslint/no-use-before-define": [
+      "error",
+      {
+        "functions": true,
+        "classes": true,
+        "variables": false
+      }
+    ],
     "@typescript-eslint/no-var-requires": 0
   }
 }
 ```
 
 Lass uns jetzt einen kurzen Blick auf die unterschiedlichen Teile der config Datei werfen:
-* **"extends"** => unsere Presets der Regeln
-* **"parser"** => zeigt auf unseren Typescript-Parser
-* **"parserOptions"** => wie der Name schon sagt
-* **"plugins"** => einige Plugins für unsere Bequemlichkeit
-* **"rules"** => hier fügen wir unsere eigenen Regeln ein und überschreiben Presets aus dem **"extends"** Bereich, mit denen wir nicht einverstanden sind
 
-Zuletzt müssen wir jetzt noch unsere .prettierrc config Datei hinzufügen. Es gibt nur wenige geringfügige Anpassungen, die wir hier vornehmen müssen, da die meisten Dinge, die wir reparieren möchten, bereits durch unsere eslint Regeln abgedeckt sind. Füge einfach eine neue .prettierrc Datei am root level mit diesen fünf Zeilen hinzu.
+- **"extends"** => unsere Presets der Regeln
+- **"parser"** => zeigt auf unseren Typescript-Parser
+- **"parserOptions"** => wie der Name schon sagt
+- **"plugins"** => einige Plugins für unsere Bequemlichkeit
+- **"rules"** => hier fügen wir unsere eigenen Regeln ein und überschreiben Presets aus dem **"extends"** Bereich, mit denen wir nicht einverstanden sind
 
+Zuletzt müssen wir jetzt noch unsere .prettierrc config Datei hinzufügen. Es gibt nur wenige geringfügige Anpassungen, die wir hier vornehmen müssen, da die meisten Dinge, die wir reparieren möchten, bereits durch unsere eslint Regeln abgedeckt sind. Füge einfach eine neue .prettierrc Datei am root level mit diesen fünf Zeilen hinzu.
 
 **File:** /.prettierrc
 
@@ -241,7 +247,7 @@ Zuletzt müssen wir jetzt noch unsere .prettierrc config Datei hinzufügen. Es g
 }
 ```
 
-Wenn du es mit sauberem Code in deinem Repository ganz genau nehmen willst,  kannst du noch einen Schritt weiter gehen und den Linter ausführen, bevor du neuen Code als Commit akzeptierst. Ich arbeite nicht mit einem Pre-Commit hook, der es komplett verhindert, Code mit Linting Fehlern ins Repository zu pushen. Für dich könnte dieses Vorgehen aber das Richtige sein und ich kann dir  nur empfehlen, dafür einen Blick auf Husky zu werfen. Da ich in meinen Projekten aber viel Prototyping durchführe und mein Workflow Codeüberprüfungen enthält, bevor ich etwas in meine Entwicklung oder in main branches einfüge, schränke ich mich diesbezüglich nicht ein.
+Wenn du es mit sauberem Code in deinem Repository ganz genau nehmen willst, kannst du noch einen Schritt weiter gehen und den Linter ausführen, bevor du neuen Code als Commit akzeptierst. Ich arbeite nicht mit einem Pre-Commit hook, der es komplett verhindert, Code mit Linting Fehlern ins Repository zu pushen. Für dich könnte dieses Vorgehen aber das Richtige sein und ich kann dir nur empfehlen, dafür einen Blick auf Husky zu werfen. Da ich in meinen Projekten aber viel Prototyping durchführe und mein Workflow Codeüberprüfungen enthält, bevor ich etwas in meine Entwicklung oder in main branches einfüge, schränke ich mich diesbezüglich nicht ein.
 
 Um den Linter auszuführen und Gebrauch von den Prettier Autokorrekturen machen zu können, müssen wir zwei neue Skripte zu unserem package.json hinzufügen.
 
@@ -261,8 +267,8 @@ Ich persönlich habe es nicht so gerne, jedes mal 10 Linien nutzlose "npm ERR!"
 
 ![Terminal – Ausführen von TypeScript-Check und ESLint](./console.png)
 
-
 ## Zusammenfassung
+
 Wenn du jetzt die Linter Skripte ausführst, wirst du zwei Dinge beobachten.
 Das Ausführen von `npm run lint` wird dir eine lange Liste kleinerer Probleme zeigen. Dies liegt nicht daran, dass das basic template Fehler enthält, sondern dass unsere selbst definierten Regeln unterschiedliche Paradigmen aufweisen (wie meine Präferenz, keine Semikolons zu verwenden, trailing comma zu erzwingen und einen Einzug von 4 zu verwenden).
 
@@ -276,13 +282,12 @@ Der verbleibende Fehler ist ein fehlender return type, also lasst uns diesen Feh
 
 ![Terminal – Return-Type ergänzt, Linter meldet keine Fehler mehr](./console-4.png)
 
-
 ## Fazit
+
 Wir haben ein neues Projekt mit einem Typescript Template gestartet, haben linting und eslint Typescript Support hinzugefügt und unsere Regeln so angepasst, dass sie passend erschienen. Außerdem haben wir Prettier's Autokorrektur-Fähigkeit mit einbezogen und damit das Ziel der heutigen Reise erreicht.
 
 In unserer nächsten Session werden wir einen Blick auf grundlegende Lösungen für die Navigation, das state management und die Struktur der Projektdateien werfen.
 
 Hier ist der versprochene [Link zum (Pre-)Release tag auf Github](https://github.com/AllBitsEqual/expo-ts-starter/tree/v0.1.0).
 
 [Hier zum Original-Artikel auf English](https://allbitsequal.medium.com/series-react-native-step-by-step-working-with-typescript-and-linting-3961c4226793){:rel="noopener noreferrer nofollow"}.
-
diff --git a/src/content/posts/de/2021-05-31-abe-react-redux-toolkit-with-typescript/index.md b/src/content/posts/de/2021-05-31-abe-react-redux-toolkit-with-typescript/index.md
@@ -1,5 +1,5 @@
 ---
-title: "Reihe: React Native (Schritt für Schritt) – React Redux und Redux Toolkit mit TypeScript"
+title: "Reihe: React Redux & Redux Toolkit mit TypeScript (React Native)"
 description: "Setting up React Redux using the Redux Toolkit with Typescript in Expo "
 author: "Konrad Abe (AllBitsEqual)"
 published_at: 2021-05-31T10:00:00.000Z
