ytnozto

TheRealFuture42

_gregor_paul_

hello@sil3ntrunning.net

Als ich mich an meinen kleinen persönlichen (React) TypeScript-Leitfaden gesetzt habe, wusste ich noch nicht, dass es dazu in der Community eine Diskussion gibt, wie und wann typisiert werden sollte. Da ich mir selbst die Frage auch gestellt habe, möchte ich hier kurz aufzeigen, wie meine Erkenntnisse dazu sind.

Lass mir gern ein Kommentar da, wenn du es anders siehst!

# Wann solltest du typisieren?

**Verwende Typisierung bei**

1. Objekten oder Arrays
2. Funktionen und Methoden
3. Generische Typen: Hooks oder andere generische Funktionen
4. Externe Daten, z.B. wenn sie von einer API stammen

**Wann du nicht Typisieren musst**

1. Einfache Typen, z.B. `const count = 10;` da hier TypeScript automatisch ableiten kann das count eine number ist.
2. Hooks mit Initialwerten z.B. `const [isVisible, setIsVisible] = useState(false);` der Initialwert gibt hier den Typ an.

**Vorteile der expliziten Typisierung**

Einer der Hauptgründe, der für eine Typisierung spricht, ist in meinen Augen, dass explizite Typen als Dokumentation für deinen Code dienen. Andere Entwickler (oder du selbst in der Zukunft) können sofort sehen, welche Typen erwartet werden. Das schafft Sicherheit und andere können deinen Code besser verstehen.

Explizite Typen können helfen, Fehler frühzeitig zu erkennen, insbesondere in größeren Codebasen.

**Nachteile der expliziten Typisierung**

Ich gebe zu, ich habe nicht viele Gründe finden können, die gegen eine explizite Typisierung sprechen. Aber ich möchte zumindest einen Gedanken dazu mitgeben.

1. Das Hinzufügen von Typen zu jedem einzelnen Wert kann den Code unnötig aufblähen und die Verwaltung erschweren.
2. Wenn du weitere Nachteile kennst, schreibs in die Kommentare :)

**Fazit**

Wie du sicher schon mitbekommen hast, gehöre ich zur Kategorie "Everything needs a type". Ich denke, es ist nicht wirklich zielführend inkonsistent zu typisieren, auch wenn es nicht immer nötig ist, empfinde ich einen konsistenten Weg zielführender als irgendwas dazwischen.

## Wie du typisierst

## Einfache Typen

Ich denke, das hier ist selbsterklärend.

```typescript
const count: number = 10;
```

## Funktionen und Methoden

Bei der Definition von Funktionen und Methoden gibst du die Typen der Parameter und des Rückgabewerts an.

```typescript
function add(a: number, b: number): number {
  return a + b;
}
```

## Generische Typen (Generics)

Damit ich den Generics gerecht werde muss ich hier etwas tiefer eintauen. Also konzentrieren, es ist ein wichtiger Teil von TypeScript!

Generics ermöglichen es dir, typsicheren Code zu schreiben, der zur Kompilierzeit überprüft wird. Generics bieten eine flexible Möglichkeit, mit verschiedenen Typen zu arbeiten, ohne den Typ im Voraus festlegen zu müssen. Du kannst generische Funktionen, Klassen und Interfaces erstellen, die mit verschiedenen Typen arbeiten können, ohne den Code duplizieren zu müssen.

Wenn du generische Typen verwendest, wie bei useRef, useState oder anderen generischen Funktionen gibst du den Type explizit an. Das bedeutet, dass der generische Typ in diesem Fall nicht flexibel ist, sondern auf `HTMLInputElement` festgelegt wird. Lass uns das genauer betrachten.

```typescript
const inputRef = useRef<HTMLInputElement>(null);
const [isVisible, setIsVisible] = useState<boolean>(false);
```

Der große Vorteil von Generics ist aber wie oben schon erwähnt, dass du mit verschiedene Typen arbeiten kannst, ohne den Typ im Voraus festlegen zu müssen.

**Hee? What?**

Ja du hast richtig gelesen, dass ganze geht zur Laufzeit, daher hier erstmal der Code. Ich erkläre danach, was hier passiert.

```typescript
interface Person {
  name: string;
  age: number;
}

// Die Funktion teilt ein Array von Objekten in mehrere Teile auf
function splitArray<T>(array: Array<T>, numParts: number): Array<Array<T>> {
  const result: Array<Array<T>> = [];

  for (let i = 0; i < array.length; i++) {
    const index = i % numParts;
    if (!result[index]) {
      result[index] = [];
    }
    result[index].push(array[i]);
  }

  return result;
}

const persons: Person[] = [
  { name: 'Alice', age: 30 },
  { name: 'Bob', age: 25 },
  { name: 'Charlie', age: 35 },
  { name: 'Diana', age: 28 },
];

const splitPersons = splitArray(persons, 2);
console.log(splitPersons);
// Ausgabe: [[{ name: "Alice", age: 30 }, { name: "Charlie", age: 35 }], [{ name: "Bob", age: 25 }, { name: "Diana", age: 28 }]]
```

**`<T>`**: Der generische Typ T ist ein Platzhalter für den Typ, der zur Laufzeit festgelegt wird.  
**`array: Array<T>`**: Der Parameter array ist ein Array von Elementen des Typs T.  
**`Array<Array<T>>`**: Die Rückgabe ist ein Array von Arrays, wobei jedes innere Array Elemente des Typs T enthält.

Du hast noch nicht ganz verstanden, wie wir Typsicherheit erreichen, obwohl wir die Typen nicht vorweg festlegen? Ich versuche es hier an einer Analogie zu erklären.

Stell dir vor, du hast eine spezielle Box, die alles Mögliche aufnehmen kann: Bücher, Spielzeug, Kleidung usw. Diese Box hat jedoch eine besondere Eigenschaft: Sobald du etwas hineinlegst, kann sie nur noch Dinge desselben Typs aufnehmen. Wenn du also ein Buch hineinlegst, kann die Box nur noch Bücher aufnehmen. Das sorgt dafür, dass du nicht versehentlich ein Spielzeug in eine Box legst, die für Bücher gedacht ist.

Generics funktionieren ähnlich wie diese Box. Sie ermöglichen es dir, eine Funktion, Klasse oder ein Interface zu definieren, die mit verschiedenen Typen arbeiten kann. Sobald du jedoch einen bestimmten Typ verwendest, sorgt TypeScript dafür, dass nur dieser Typ verwendet wird, was Typsicherheit gewährleistet.

Ich zeigs hier noch einmal an einem simpleren Beispiel, wir haben hier eine Funktion, die einfach den Wert zurückgibt, den sie erhält.

```typescript
function identity<T>(value: T): T {
  return value;
}
```

Wir rufen diese Funktion jetzt einfach mit einem String auf.

```typescript
const result1 = identity<string>('Hello, World!');
console.log(result1); // Ausgabe: "Hello, World!"
```

Wir rufen dieselbe Funktion mit einer Number auf.

```typescript
const result2 = identity<number>(42);
console.log(result2); // Ausgabe: 42
```

TypeScript stellt in jeweils beiden Funktionsaufrufen sicher, dass der Typ entweder vom Type String bei "result1" ist oder von Type Number bei "result2".

## Externe Daten

Wenn du Daten von einer externen Quelle (z.B. einer API) erhältst, ist es hilfreich, die erwartete Struktur der Daten zu typisieren. Dies geschieht z.B. über ein "interface" würde aber auch anonymisiert oder mit einem Type-Alias gehen. Da gehe ich aber weiter unten noch genauer drauf ein wo da die Unterschiede liegen.

```typescript
interface ApiResponse {
  data: string;
  status: number;
}

async function fetchData(): Promise<ApiResponse> {
  const response = await fetch('/api/data');
  return response.json();
}
```

# DOM-Typen

Wenn du dir mein Beispiel der Generische Typen genau angeschaut hast wirst du gesehen haben, dass ich bei dem useRef-Hook eine generische Typendefinition angewandt habe, die ich selbst nicht erstellt habe, `<HTMLInputElement>`. Dies nennt man "DOM-Typen oder DOM-Interfaces". Diese sind Teil der TypeScript-Typdefinitionen, welche mit der TypeScript-Standardbibliothek mitgebracht werden. Diese Typen decken eine Reihe von DOM-Elementen und Schnittstellen ab, die in Webanwendungen verwendet werden.

## Wie finde ich die Typendefinitionen

Es gibt verschiedene Quellen, welche du nutzen kannst um an die Typendefinitionen zukommen. Du kannst die [Dokumentation von TypeScript](https://www.typescriptlang.org/docs/) nutzen oder den Quellcode von TypeScript anschauen, du findest die Typendefinitionen in der Datei `lib.dom.d.ts`. Der für mich aber beste Weg war bisher über die [MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/API), diese ist eine hervorragende Ressource für Informationen rund um die Web-APIs und der entsprechenden Typen. [Beispiel unser "HTMLInputElement"](https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement)

**Beispielhafte DOM-Typen:**

HTMLInputElement: Repräsentiert ein `<input>`-Element.  
HTMLButtonElement: Repräsentiert ein `<button>`-Element.  
HTMLElement: Der Basistyp für alle HTML-Elemente.  
Event: Der Basistyp für alle Ereignisse.

## "Interfaces" oder "Type Aliases"?

Ein wichtiger Teil von TypeScript sind Interfaces und Type Aliase. Beides ist essenziell, da diese eigentlich fast in jedem Projekt zur Anwendung kommen. Wenn du diese und die Punkte davor kennst und weißt, wie du sie einsetzt, dann hast du 90 % von dem, was du im Alltag brauchst, um mit React und TypeScript zuarbeiten. Zumindest ist es das, was ich bisher am meisten benötigt habe.

## Type-Alias

Type Alias verwendest du für primitive Typen, Union Types, Intersection Types, Tupel und komplexe Typenkombinationen. Type Aliase könne nicht erweitert werden, aber sie lassen sich kombinieren.

**Union Types (Primitive Typen)**

Ein Union Type kann Typen kombinieren, und ein Wert dieses Typs kann einer der enthaltenen Typen sein.

Primitive Union Types kombinieren primitive Typen wie string oder number.

```typescript
type ID = string | number;

let userId: ID;

userId = 'abc123'; // OK
userId = 123; // OK
userId = true; // Fehler: 'true' ist kein 'string' oder 'number'
```

**Union Types (Komplexe Types)**

Komplexe Union Types kombinieren komplexe Typen wie Objekte oder Klassen.

```typescript
type SuccessResponse = {
  status: 'success';
  data: any;
};

type ErrorResponse = {
  status: 'error';
  error: string;
};

type Response = SuccessResponse | ErrorResponse;

function handleResponse(response: Response) {
  if (response.status === 'success') {
    console.log('Data:', response.data);
  } else {
    console.log('Error:', response.error);
  }
}

const success: Response = { status: 'success', data: { id: 1, name: 'Item' } };
const error: Response = { status: 'error', error: 'Something went wrong' };

handleResponse(success); // Data: { id: 1, name: "Item" }
handleResponse(error); // Error: Something went wrong
```

**Intersection Types**

Ein Intersection Type kombiniert mehrere Typen zu einem neuen Typ, der alle Eigenschaften der kombinierten Typen enthält. Ein Wert, der einem Intersection Type entspricht, muss alle Eigenschaften der kombinierten Typen haben.

In dem folgenden Beispiel ist EmployeePerson ein Intersection Type, der alle Eigenschaften von Person und Employee kombiniert. Ein Objekt vom Typ EmployeePerson muss also name, age und employeeId haben.

```typescript
type Person = {
  name: string;
  age: number;
};

type Employee = {
  employeeId: number;
};

type EmployeePerson = Person & Employee;

const employee: EmployeePerson = {
  name: 'John Doe',
  age: 30,
  employeeId: 1234,
};
```

**Tupel**

Wir können mit TypeScript auch Tupel typisieren, also Werte mit einer festen Anzahl von Elementen.

Hier ein kleines Beispiel, Point erwartet immer zwei Elemente vom Typ number.

```typescript
type Point = [number, number];

const point: Point = [10, 20]; // Korrekt

const invalidPoint: Point = [10, '20']; // Fehler: Das zweite Element muss eine Zahl sein

const anotherInvalidPoint: Point = [10]; // Fehler: Es müssen genau zwei Elemente sein
```

## Interfaces

Ein Interface ist eine Struktur, die beschreibt, wie ein Objekt aussehen soll. Interfaces sind besonders nützlich für die Beschreibung von Objekten und Klassen und unterstützen Vererbung und Deklarationszusammenführung. Interfaces kann nicht für primitive Typen oder Unions Types verwendet werden.

**Objektstrukturen**

So schaut die Struktur eines Objektes aus:

```typescript
interface Person {
  name: string;
  age: number;
}
```

**Vererbung**

Du kannst bei Interfaces von einem anderen Interface ableiten.

```typescript
interface Person {
  name: string;
  age: number;
}

interface Employee extends Person {
  employeeId: number;
}

const employee: Employee = {
  name: 'John Doe',
  age: 30,
  employeeId: 1234,
};
```

**Deklarationszusammenführung**

Wenn du mehrere Deklarationen desselben Interfaces haben möchtest, die zu einem einzigen Interface zusammengeführt werden.

```typescript
interface Person {
  name: string;
}

interface Person {
  age: number;
}

// Das resultierende Interface Person hat sowohl name als auch age
const person: Person = { name: 'John', age: 30 };
```

Ich denke, nun kennst du alles Wichtige zu Interfaces und Type Aliases. Beide Ansätze haben ihre eigenen Stärken und Schwächen, und die Wahl zwischen ihnen hängt oft von den spezifischen Anforderungen deines Projekts ab. Wenn du weitere Fragen hast oder mehr Beispiele benötigst, lass es mich wissen!


Grundlagen der Typisierung in TypeScript: Wann und wie man typisiert, Generics, DOM-Typen, Interfaces und Type Aliases.

thumbnail-v1-TypeScript.png

Wann und Wie du typisierst

TypeScript: Typisierungs-Leitfaden

typescript

## React Hooks: Vorwort

  
In dieser Reihe schauen wir uns die verschiedenen React Hooks an und wie wir sie einsetzen können. Ich verfolge dabei keinen tieferen Plan oder ein Skript, daher könnte es gut möglich sein, dass du dich jetzt fragst, wieso fängt der denn jetzt mit dem useRef\-Hook an? Ehrlich gesagt, weiß ich das auch nicht. Seht es mir also nicht nach, ich schreibe hier einfach nur Dinge nieder, und vielleicht hilft es ja doch jemandem da draußen. 

Lange Rede, kurzer Sinn, lasst uns beginnen.

## Wozu dient der useRef Hook?

Der useRef\-Hook in React dient dazu, Referenzen auf DOM-Elemente oder andere mutable Objekte zu erstellen, die während des gesamten Lebenszyklus einer Komponente bestehen bleiben. Im gegensatz zu State-Änderungen, welche ein Re-Rendering auslösen, führt eine Referenz mit useRef nicht zu einem erneuten Rendern der Komponente. 

useRef wird häufig verwendet, um Werte zu speichern, die über Renderings hinweg persistent bleiben sollen, aber nicht in den Render-Prozess einbezogen werden müssen. Beispiele dafür sind das Speichern von DOM-Referenzen, Timer-IDs oder anderen mutierbaren Werten, die keinen Einfluss auf das UI haben.

Um es hier auf den einfachsten Weg darzustellen, wofür der useRef im Kern genutzt werden kann, hier ein kleines Beispiel um den Fokus durch Klick auf einen Button auf das Input Feld zu setzen. 

```javascript
import { useRef } from 'react';

function TextInputWithFocusButton() {
  const inputElement = useRef<HTMLInputElement>(null);

  const onButtonClick = () => {
    // `current` points on the Input-element
    inputElement.current?.focus();
  };

  return (
    <>
      <input ref={inputElement} type="text" />
      <button onClick={onButtonClick}>Focus</button>
    </>
  );
}
```

## Was passiert hier?

  
Wir rufen useRef auf der obersten Ebene unserer Komponente auf. Wir sind hier nicht limitiert und könnten auch weitere Refs deklarieren.

useRefgibt ein Ref-Objekt zurück, mit einer current property,welche wir auf einen Anfangswert gesetzt haben (null).

```typescript
import { useRef } from 'react';

function TextInputWithFocusButton() {
  const inputElement = useRef<HTMLInputElement>(null);
	// ...
```

Dann übergeben wir unser Ref-Objekt deminputElementals ref\-Attribut an das JSX des Dom-Knotens.

```typescript
  return (
    <>
      <input ref={inputElement} type="text" />
      <button onClick={onButtonClick}>Focus</button>
    </>
  );
```

Nachdem React den DOM-Node  erstellt und auf den Bildschirm anzeigt, setzt React die current Eigenschaft ihres Ref-Objekts auf diesen DOM-Node. Damit können wir nun auf das `<input>` Feld zugreifen und Methoden wie focus() aufrufen.

```typescript
  const onButtonClick = () => {
    // `current` points on the Input-element
    inputElement.current?.focus();
  };
```

## Weitere Anwendungsfälle für useRef

Ein typischer Anwendungsfall wäre zum Beispiel der Einsatz bei One-Pager-Applikationen, wo wir zu bestimmten Punkten springen möchten. Mit useRef haben wir Zugriff auf Browser-Methoden wie scrollIntoView(), um zu diesen Punkten zu scrollen.

Weiterführende Links:  
  
https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/focus

https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement

https://react.dev/learn/manipulating-the-dom-with-refs

In dieser Reihe schauen wir uns die verschiedenen React Hooks an und wie wir sie einsetzen können.

thumbnail-v1-useRef.png

React Hooks vorgestellt

React Hooks: Der useRef Hook

react

In diesem Beitrag zeige ich euch, wie man mit Server Actions in Next.js arbeitet. Keine Sorge, ich werde es einfach halten und mich nicht in die hitzige Diskussion einmischen, ob es eine gute Idee ist, Server-Logik und Client-Logik zu vermischen. Aber weil diese Diskussion so kontrovers ist (und es immer noch bleibt), möchte ich euch dieses amüsante Meme dazu nicht vorenthalten.

 ![{{ w: 1000, h: 300 }}](/uploads/server_action_is_crazy_v0_yloxtuizn3xb1_4281400aa9.webp) 

Um dieses Bild richtig zu verstehen, solltet ihr euch den Vortrag von Vercel ansehen, in dem das Feature der Server Actions erstmals vorgestellt wurde.

[Hier geht's zum Video.](https://www.youtube.com/watch?v=9CN9RCzznZc)

Da einige ziemlich irritiert davon waren, serverseitigen Code innerhalb von clientseitigem Code auszuführen, und dies von vielen Seiten kritisiert wurde, hat das Internet natürlich direkt ein paar Memes dazu erfunden. Ein gutes Beispiel dafür ist das 2D-Game Redstone-Meme hier.

Ob sich die Server Actions letztendlich durchsetzen werden, wird die Zeit zeigen. Die Community ist dazu gespalten.

## Kopf in den Nacken & Los geht's

Leider komme auch ich nicht ganz um ein bisschen Einführung und Theorie herum. Also hier das Wichtigste: Mit der Einführung des App-Routers in Next.js 13.4 wurde ein neues Feature namens Server Actions vorgestellt. Dieses Konzept soll die Entwicklung von Webanwendungen optimieren, indem es die Kommunikation zwischen Client und Server verbessert und unnötige Komplexität reduziert. Mit Server Actions können bestimmte Aktionen direkt auf dem Server ausgeführt werden, anstatt sie auf der Client-Seite zu behandeln und dann über die /api an den Server weiterzugeben. Dadurch wird die Anwendungsarchitektur vereinfacht, die Leistung verbessert und eine klarere Trennung zwischen Client- und Server-Aufgaben erreicht.

Seit Next.js 14 sind Server Actions offiziell als stabiles Feature verfügbar, und wir können jetzt von den Vorteilen profitieren, wie zum Beispiel der Reduzierung von Client-Server-Roundtrips und der Möglichkeit, serverseitige Mutationen durchzuführen. Allerdings gab es auch einige Kritikpunkte an der Einführung von Server Actions (siehe unser Meme). Einige sahen Ähnlichkeiten zur Arbeitsweise von PHP und kritisierten die Vermischung von Zuständigkeiten zwischen Client und Server. Auch Bedenken hinsichtlich der Skalierbarkeit und Serverbelastung wurden geäußert. Daher ist es wichtig, sorgfältig abzuwägen, ob und wie Server Actions in einem Projekt eingesetzt werden sollten, um die bestmögliche Architektur und Leistung zu erzielen.

Server Actions müssen explizit als solche markiert werden. Das geschieht mit der Anweisung "use server";. Wir werden im Laufe unserer Beispiele noch näher darauf eingehen. Ein Vorteil von Server Actions ist, dass wir Async/Await in unseren Komponenten verwenden können, da Server Actions auf dem Server ausgeführt werden. Was jedoch nicht möglich ist, sind clientseitige React Hooks wie useEffect, useMemo usw. Diese können wie gewohnt nur in Client Components verwendet werden.

Es gibt verschiedene Möglichkeiten, wie wir Server Actions einsetzen können: In einem Formelement, durch Event Handler oder auch in einem useEffect-Hook. Ich werde hier auf alle Varianten mit Beispielen eingehen und hoffe, dass es euch weiterhilft und ihr danach etwas mehr Klarheit habt.

## Server Actions in form Elementen

React hat das HTML <form>-Element mit der Prop action erweitert, die es uns ermöglicht, Server Actions direkt beim Absenden des Formulars auszuführen.

```jsx
  return (
    <form action={createPost}>
      <label className="block">Title</label>
      <input type="text" name="title" className="block mb-2" />

      <label className="block">Text</label>
      <textarea
        name="post-text"
        rows={4}
        className="block mb-2"
        placeholder="Post Text"
      ></textarea>
      <button type="submit" className="bg-slate-600 p-2">
        Create Post
      </button>
    </form>
  );
```
Wenn wir die Action in einem `<form>`-Element aufrufen, erhält sie automatisch das [FormData](https://developer.mozilla.org/en-US/docs/Web/API/FormData/FormData)-Objekt. Mit diesem Objekt sind wir nicht mehr auf den React Hook `useState` angewiesen, um die Felder zu verwalten. Stattdessen können wir die nativen Methoden von [FormData](https://developer.mozilla.org/en-US/docs/Web/API/FormData#instance_methods) nutzen und darauf zugreifen.

```jsx
export default function CreatePostForm() {
  async function createPost(formData: FormData) {
    'use server';

    const data = {
      title: formData.get('title') as string,
      body: formData.get('post-text') as string,
    };

    await createPostAction(data);
  }
```
Zuerst kennzeichnen wir mit `"use server";` unsere Funktion explizit als Server Action.

Die eigentliche Verarbeitung haben wir in eine extra Datei namens "action.ts" ausgelagert. Es wäre aber auch möglich, die Funktionalität direkt in unsere Server-Komponente einzufügen, und es würde sogar als Inline-Code innerhalb der `action`-Prop in unserem Formelement funktionieren.

Hier geht es zu unserem **[Beispielcode.](https://stackblitz.com/edit/nextjs-server-actions-form?file=lib%2Factions.ts)**

> Schaut euch auch die [Dokumentation](https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations#forms) dazu an dort wird das ganze noch weiter vertieft.

## Server Actions mit Event Handler

Wie schon am Anfang gesagt, lassen sich Server Actions auch außerhalb von Formelementen aufrufen.

Lasst uns also die Möglichkeit betrachten, Server Actions mit Event-Handlern (onClick, onChange, ...) aufzurufen.

Dazu haben wir ein kleines Programm geschrieben, das durch einen Klick auf den Button "Click me" die Server Action aufruft. Dabei wird ein Fake-Eintrag bei unserer API erstellt und die Antwort an unsere Client-Komponente "ShowPost.tsx" weitergegeben.

```jsx
'use client';

import { createPostAction } from '@/lib/actions';
import { useState } from 'react';
import ShowPost from '@/components/ShowPost';
import { Post } from '@/lib/types';

export default function CreatePost() {
  const [post, setPost] = useState<Post>();

  return (
    <>
      <button
        className="bg-stone-500 p-1 rounded"
        onClick={async () => {
          const createPost = await createPostAction();
          setPost(createPost);
        }}
      >
        Click me
      </button>
      <div className="pt-10">{post && <ShowPost post={post} />}</div>
    </>
  );
}
```
Ich denke, dass mein Beispiel hier ganz gut erklärt, was eigentlich passiert. Die onClick-Methode ruft in einer Async-Funktion die Server Action auf und schreibt die Antwort mit dem Hook useState in die Variable "post".

Den kompletten Code dazu könnt ihr euch hier [**anschauen**](https://stackblitz.com/edit/nextjs-server-actions-event-handler-method?file=components%2FCreatePost.tsx). 

## Server Actions mit useEffect aufrufen

Eine weitere Möglichkeit ist es, innerhalb von Client-Komponenten mit dem React useEffect-Hook Server Actions aufzurufen. Ich werde hier kurz darauf eingehen, und am Ende findet ihr wieder den Link zu meinem Code-Beispiel.

Bei jedem Reload der Seite holen wir uns mit unserem useEffect-Hook alle Einträge von unserer API.

```jsx
'use client';

import { useEffect, useState } from 'react';
import { getPostsAction } from '@/lib/actions';
import { Post } from '@/lib/types';

export default function ShowPosts() {
  const [posts, setPosts] = useState<Post[]>([]);

  useEffect(() => {
    const fetchPosts = async () => {
      try {
        const posts = await getPostsAction();
        setPosts(posts);
      } catch (error) {
        console.log(error);
      }
    };

    fetchPosts();
  }, []);

  return (
    <div>
      <ul>
        {posts.map((posts) => (
          <li className="my-5" key={posts.id}>
            {posts.id}. {posts.title}
          </li>
        ))}
      </ul>
    </div>
  );
}
```
Es wird bei jedem Seiten-Reload die API aufgerufen `const posts = await getPostsAction();`, die Antwort unseres Servers speichern wir nun mit useState in einer Variable und liefern sie an unser Frontend aus.

Hier geht es zu dem [Beispielcode](https://stackblitz.com/edit/nextjs-server-actions-useeffect-method?file=components%2FShowPosts.tsx).

## Error Handling mit Server Actions

In unseren bisherigen Beispielen haben wir gänzlich auf die Fehlerbehandlung im Frontend verzichtet, daher würde ziemlich großer Wahrscheinlichkeit unsere App bei Fehlern abstürzen. Deswegen zeige ich hier noch, wie wir in unserem Beispiel mit `<form>`-Elementen und Server Actions Fehler abfangen können.

Damit wir dem Frontend die Fehlermeldung übergeben können, benötigen wir eine Client-Komponente. Damit unser Programm aber nicht abstürzt, müssen wir unsere Komponente dazu etwas umbauen. Da wir Server Actions inline innerhalb unseres Action-Elements in unserem `<form>`-Element aufrufen können, refaktorieren wir unseren Code aus dem ersten Beispiel so, dass wir bei einem Fehler mit useState den Fehler speichern und an unser Frontend übergeben.

Der Code vorher:

```jsx
// CreatePost.tsx

import { createPostAction } from '@/lib/actions';

export default function CreatePostForm() {
  async function createPost(formData: FormData) {
    'use server';

    const data = {
      title: formData.get('title') as string,
      body: formData.get('post-text') as string,
    };

    await createPostAction(data);
  }

  return (
    <form action={createPost}>
      <label className="block">Title</label>
      <input type="text" name="title" className="block mb-2" />

      <label className="block">Text</label>
      <textarea
        name="post-text"
        rows={4}
        className="block mb-2"
        placeholder="Post Text"
      ></textarea>
      <button type="submit" className="bg-slate-600 p-2">
        Create Post
      </button>
    </form>
  );
}
```
Wenn ihr hier auf "Create Post" geht wenn ihr nichts angegeben habt wird euch der Fehler nicht angezeigt nur wenn ihr innerhalb der Server Action die Antwort loggen würdet könntet ihr in der Server Console den Fehler sehen. Im schlimmsten fall stürzt aber auch eure App ab und um das zu verhinden zeigen weißen wir den User darauf hin das er Titel und Text angeben muss.

```ts
// actions.ts
'use server';
import { Post, PostForm } from '@/lib/types';

export async function createPostAction(postData: PostForm): Promise<Post> {
  try {
    const res = await fetch('https://jsonplaceholder.typicode.com/posts', {
      method: 'POST',
      body: JSON.stringify({
        title: postData.title,
        body: postData.body,
        userId: 1,
      }),
      headers: { 'Content-type': 'application/json; charset=UTF-8' },
    });
    // Fake response from API
    const data: Post = await res.json();

    // Show Post when click on "Create Post"
    console.log(data);

    return data;
  } catch (error) {
    console.log(error);
    throw new Error('Failed to create post');
  }
}
```

Der Code nach dem wir ihn Refaktoriert haben:

```jsx
//CreatePost.tsx
'use client';
import { createPostAction } from '@/lib/actions';
import { useState } from 'react';

export default function Form() {
  const [error, setError] = useState('');

  return (
    <form
      action={async (formData: FormData) => {
        const data = {
          title: formData.get('title') as string,
          body: formData.get('post-text') as string,
        };

        const result = await createPostAction(data);
        if ('error' in result) {
          setError(result.error);
        }
      }}
    >
      <label className="block">Title</label>
      <input type="text" name="title" className="block mb-2" />

      <label className="block">Text</label>
      <textarea
        name="post-text"
        rows={4}
        className="block mb-2"
        placeholder="Post Text"
      ></textarea>
      {error && <p className="text-red-400">{error}</p>}
      <button type="submit" className="bg-slate-600 p-2">
        Create Post
      </button>
    </form>
  );
}
```

```ts
// actions.ts
'use server';
import { Post, PostForm } from '@/lib/types';

export async function createPostAction(
  postData: PostForm
): Promise<Post | { error: string }> {
  // Check if title and body is not empty
  if (!postData.title || !postData.body) {
    return { error: 'Title and body are required.' };
  }

  try {
    const res = await fetch('https://jsonplaceholder.typicode.com/posts', {
      method: 'POST',
      body: JSON.stringify({
        title: postData.title,
        body: postData.body,
        userId: 1,
      }),
      headers: { 'Content-type': 'application/json; charset=UTF-8' },
    });
    // Fake response from API
    const data: Post = await res.json();

    // Show Post when click on "Create Post"
    console.log(data);

    return data;
  } catch (error: any) {
    console.log(error);
    return { error: error.message };
  }
}

```
Das war's auch schon! So einfach könnt ihr in Formelementen mit Fehlern umgehen. Diese können natürlich auch anders dargestellt werden, z.B. mit einer Toast-Message oder Ähnlichem.

## Fazit

In diesem Beitrag habe ich euch gezeigt, wie man mit Server Actions in Next.js arbeitet. Wir haben uns angesehen, wie Server Actions in Formelementen, durch Event-Handler und in Kombination mit dem useEffect-Hook verwendet werden können. Dabei habe ich auch erklärt, wie ihr mit Fehlern umgehen könnt.

Server Actions bieten einige Vorteile, wie die Reduzierung von Client-Server-Roundtrips und die Möglichkeit, Async/Await in euren Komponenten zu nutzen. Allerdings gibt es auch Kritikpunkte, wie die Vermischung von Zuständigkeiten zwischen Client und Server und Bedenken hinsichtlich der Skalierbarkeit.

Ob sich Server Actions letztendlich durchsetzen werden, bleibt abzuwarten, da die Community dazu gespalten ist. Aber mit etwas Übung und Anpassung könnt ihr die Vorteile dieser neuen Funktionalität voll ausschöpfen und eure Anwendungen optimieren.

Ich hoffe, dieser Beitrag hat euch einen guten Überblick gegeben und ihr habt nun mehr Klarheit darüber, wie ihr Server Actions in euren Projekten einsetzen könnt. Viel Spaß beim Ausprobieren und Entwickeln!


Next.js Server Actions: Form, Event Handler und useEffect - so geht's!

future42_Security_in_the_Web_Networked_Server_securitya_vinta_b43dd4c2-45d9-4509-9fff-08f231b8f7ef_0.png

Super Simple

Next.js Server Actions

next.js

nextjs

metropolis.png

Prinz_Monty_Coding_Future_Hacking_Binary_Website_Header_fe5f75f_1f86cac2-9fc0-4294-bcaf-dfe0dd968a98.png

SSH-Keys-Config-ed25519.png

Invalid-Regular-Expression-Image.png

oh-my-zsh-mid.png

Ice cream gingerbread danish muffin cheesecake icing tiramisu.

Biscuit dessert sweet roll cupcake sweet. Halvah jelly apple pie oat cake gummi bears marshmallow. Powder jujubes pudding gummies donut chocolate bar candy canes. Biscuit danish icing jujubes gummi bears dragée. 

CODING BITCOIN MUSIC LIFE AND EVERYTHING & MEISTENS AUF DEUTSCH

Hallo Hello היי Hola Привіт Salut أهلاً 你好 Ciao

TypeScript: Typisierungs-Leitfaden

Wann und Wie du typisierst

30.05.2024

React Hooks: Der useRef Hook

React Hooks vorgestellt

23.05.2024

Next.js Server Actions

Super Simple

14.04.2024