ytnozto

GregorWedlich

_gregor_paul_

hello@sil3ntrunning.net

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

useState.png

Basics-Trilogie

React Hooks: Der useState Hook

react

So, da sind wir wieder! Beim letzten Mal hab ich euch `useRef` gezeigt und dabei dieses mysteriöse `useEffect` in den Code geschmuggelt. Einige von euch haben sich vermutlich gefragt: "Was zur Hölle macht das denn?" Zeit, das Geheimnis zu lüften!

Warum ich mit `useRef` angefangen hab und nicht mit den "Basics"? Keine Ahnung, aber jetzt macht's Sinn - ihr habt schon gesehen, wie die Hooks zusammenspielen. Das ist wie beim Kochen: Manchmal probiert man erst das fertige Gericht und lernt dann wie es zubereitet wird.

## Die Basics-Trilogie

Dieser Artikel ist Teil zwei meiner etwas unkonventionellen "Basics-Trilogie":

1. **[Der useRef Hook](https://www.sil3ntrunning.net/blog/react-hooks-der-use-ref-hook-1)** - Das Schweizer Taschenmesser
2. **[Der useEffect Hook](https://www.sil3ntrunning.net/blog/react-hooks-der-use-effect-hook)** ← Du bist hier!
3. **[Der useState Hook](https://www.sil3ntrunning.net/blog/react-hooks-der-use-state-hook)** - Die "Basics" zum Schluss

## Für was ist der useEffect überhaupt?

`useEffect` ist Reacts Art zu sagen: "Mach das, aber erst wenn ich mit dem ganzen Render-Kram fertig bin." Es ist der Hook für Seiteneffekte - also alles, was außerhalb von React passiert. API-Calls, Timer, DOM-Manipulation, Titel ändern, LocalStorage updaten... ihr versteht schon.

Stellt euch vor, React ist wie ein Maler, der ein Bild malt (rendert). `useEffect` ist der Assistent, der wartet bis der Maler fertig ist und dann sagt: "So, jetzt häng ich das Bild auf und mach das Licht an."

## Der erste Kontakt - Ein simples Beispiel

Fangen wir ganz harmlos an:

```jsx
import { useState, useEffect } from "react";

function TitleChange() {
  const [counter, setCounter] = useState<number>(0);

  // useEffect waits until React has finished rendering
  useEffect(() => {
    console.log("Effect runs! Counter is:", counter);
    document.title = `You clicked ${counter} times`;
  });

  return (
    <div style={{ padding: "20px" }}>
      <h2>Take a look at the browser tab! 👆</h2>
      <p>Clicks: {counter}</p>
      <button onClick={() => setCounter(counter + 1)}>Click me!</button>
    </div>
  );
}

export default TitleChange;
```

Was passiert hier? Nach JEDEM Render (also auch nach jedem Klick) läuft unser Effect und updated den Dokumenten-Titel. Cool, oder? Aber Moment... nach JEDEM Render? Das klingt nach Verschwendung...

## Das Dependency Array - Die Geheimwaffe

Hier kommt der Game Changer: Das zweite Argument von `useEffect`. Es sagt React, wann der Effect laufen soll:

```jsx
import { useState, useEffect } from "react";

function EffectControl() {
  const [counter, setCounter] = useState<number>(0);
  const [name, setName] = useState<string>("");

  // Effect runs only when 'counter' changes
  useEffect(() => {
    console.log("Counter Effect:", counter);
    document.title = `Counter: ${counter}`;
  }, [counter]); // 👈 Dependency Array!

  // Effect runs only when 'name' changes
  useEffect(() => {
    console.log("Name Effect:", name);
    if (name) {
      localStorage.setItem("userName", name);
    }
  }, [name]);

  // Effect runs only ONCE on mount
  useEffect(() => {
    console.log("🎉 Component mounted!");

    // Load saved name
    const savedName: string | null = localStorage.getItem("userName");
    if (savedName) {
      setName(savedName);
    }
  }, []); // 👈 Empty array = only on mount

  return (
    <div style={{ padding: "20px" }}>
      <h2>Effect Control Demo</h2>

      <div style={{ marginBottom: "20px" }}>
        <p>Counter: {counter}</p>
        <button onClick={() => setCounter((c) => c + 1)}>+1</button>
      </div>

      <div>
        <p>Name: {name || "No name yet"}</p>
        <input
          type="text"
          value={name}
          onChange={(e) => setName(e.target.value)}
          placeholder="Your name..."
          style={{ padding: "5px" }}
        />
      </div>

      <p style={{ marginTop: "20px", fontSize: "12px", color: "#666" }}>
        Check the console for effect logs!
      </p>
    </div>
  );
}

export default EffectControl;
```

Die Regeln sind simpel:
- **Kein Array**: Effect läuft nach jedem Render
- **Leeres Array `[]`**: Effect läuft nur einmal beim Mount
- **Array mit Werten `[a, b]`**: Effect läuft wenn sich `a` oder `b` ändert

## Cleanup - Aufräumen wie ein Profi

Erinnert ihr euch an den Timer aus dem useRef Tutorial? Da war dieser mysteriöse `return` im Effect. Zeit zu erklären, was das macht:

```jsx
import { useState, useEffect } from "react";

function ChatRoom() {
  const [room, setRoom] = useState("general");
  const [messages, setMessages] = useState<string[]>([]);

  useEffect(() => {
    console.log(`➡️ Entering room: ${room}`);

    // Simulate a chat connection
    const connection = {
      room,
      active: true,
      send: (msg: string) => console.log(`Send in ${room}:`, msg),
    };

    // Simulate incoming messages
    const interval = setInterval(() => {
      if (connection.active) {
        const newMessage = `Message in ${room} at ${new Date().toLocaleTimeString()}`;
        setMessages((prev) => [...prev.slice(-4), newMessage]);
      }
    }, 3000);

    // CLEANUP FUNCTION! Runs before the next effect or on unmount
    return () => {
      console.log(`⬅️ Leaving room: ${room}`);
      connection.active = false;
      clearInterval(interval);
    };
  }, [room]); // Effect runs again when the room changes

  return (
    <div style={{ padding: "20px" }}>
      <h2>Chat Room Simulator</h2>

      <div style={{ marginBottom: "20px" }}>
        <button
          onClick={() => setRoom("general")}
          style={{
            marginRight: "10px",
            fontWeight: room === "general" ? "bold" : "normal",
          }}
        >
          #general
        </button>
        <button
          onClick={() => setRoom("random")}
          style={{
            marginRight: "10px",
            fontWeight: room === "random" ? "bold" : "normal",
          }}
        >
          #random
        </button>
        <button
          onClick={() => setRoom("help")}
          style={{ fontWeight: room === "help" ? "bold" : "normal" }}
        >
          #help
        </button>
      </div>

      <div
        style={{
          background: "#5d5555",
          padding: "10px",
          borderRadius: "5px",
          minHeight: "150px",
        }}
      >
        <h3>Messages in #{room}:</h3>
        {messages.length === 0 ? (
          <p style={{ color: "#666" }}>Waiting for messages...</p>
        ) : (
          messages.map((msg, i) => (
            <p key={i} style={{ margin: "5px 0" }}>
              💬 {msg}
            </p>
          ))
        )}
      </div>

      <p style={{ fontSize: "12px", color: "#666", marginTop: "10px" }}>
        Check the console! You can see when rooms are entered/left.
      </p>
    </div>
  );
}

export default ChatRoom;
```
Die Cleanup-Funktion im useEffect-Hook ist wichtig, um Memory Leaks zu verhindern, da sie sicherstellt, dass der Interval-Timer gestoppt und die Verbindung zurückgesetzt wird, bevor ein neuer Raum betreten wird oder die Komponente unmounted. Ohne dieses Aufräumen würden die Intervalle weiterlaufen und mehrfach erstellt werden, was zu Ressourcenverschwendung und unvorhersehbarem Verhalten führen kann.

Die Cleanup-Function ist wie der Hausmeister - räumt auf, bevor der nächste reinkommt!

## Data Fetching - Der Klassiker

Kein useEffect Tutorial ohne API-Calls! Aber Achtung, hier gibt's Fallen:

```jsx
import { useState, useEffect } from "react";

interface GitHubUserData {
  login: string;
  name: string | null;
  avatar_url: string;
  location: string | null;
  public_repos: number;
  followers: number;
  bio: string | null;
}

function GitHubUser() {
  const [username, setUsername] = useState<string>("torvalds");
  const [userData, setUserData] = useState<GitHubUserData | null>(null);
  const [loading, setLoading] = useState<boolean>(false);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    // Important: We can't use an async function directly in useEffect!
    const fetchUser = async () => {
      setLoading(true);
      setError(null);

      try {
        const response = await fetch(
          `https://api.github.com/users/${username}`
        );

        if (!response.ok) {
          throw new Error("User not found!");
        }

        const data = await response.json();
        setUserData(data);
      } catch (err: unknown) {
        const errorMessage =
          err instanceof Error ? err.message : "Unknown error occurred";
        setError(errorMessage);
        setUserData(null);
      } finally {
        setLoading(false);
      }
    };

    // Only fetch if username exists
    if (username) {
      fetchUser();
    }

    // Cleanup is not needed here, but we could use an
    // AbortController to cancel requests
  }, [username]); // Fetch again when username changes

  return (
    <div style={{ padding: "20px", maxWidth: "400px" }}>
      <h2>GitHub User Finder</h2>

      <input
        type="text"
        value={username}
        onChange={(e) => setUsername(e.target.value)}
        placeholder="GitHub Username..."
        style={{
          width: "100%",
          padding: "8px",
          marginBottom: "20px",
          fontSize: "16px",
        }}
      />

      {loading && <p>🔄 Loading...</p>}

      {error && <p style={{ color: "red" }}>❌ Error: {error}</p>}

      {userData && !loading && (
        <div
          style={{
            background: "#5c4c4c",
            padding: "20px",
            borderRadius: "10px",
          }}
        >
          <img
            src={userData.avatar_url}
            alt={userData.name || userData.login}
            style={{
              width: "100px",
              borderRadius: "50%",
              marginBottom: "10px",
            }}
          />
          <h3>{userData.name || userData.login}</h3>
          <p>📍 {userData.location || "Unknown"}</p>
          <p>📦 Public Repos: {userData.public_repos}</p>
          <p>👥 Followers: {userData.followers}</p>
          {userData.bio && <p>💬 {userData.bio}</p>}
        </div>
      )}
    </div>
  );
}

export default GitHubUser;
```

## Die häufigsten Fallen und wie ihr sie vermeidet

### Falle 1: Der Infinite Loop

```jsx
// ❌ FALSCH - Infinite Loop!
function InfiniteLoop() {
  const [count, setCount] = useState(0);
  
  useEffect(() => {
    // This triggers a re-render, which triggers the effect, which...
    setCount(count + 1);
  }); // No dependency array = runs after EVERY render!
  
  return <div>I’m going to crash your browser: {count}</div>;
}

// ✅ CORRECT - Controlled Effect
function ControlledCounter() {
  const [count, setCount] = useState(0);
  
  useEffect(() => {
    // Runs only once on mount
    setCount(1);
  }, []); // Empty array!
  
  return <div>Safe counter: {count}</div>;
}
```
Was passiert hier? Der Effect ändert den State, was ein Re-Render auslöst, was den Effect wieder ausführt, was den State ändert... und dein Browser sagt irgendwann "Mir reicht's!" Das ist wie eine Katze, die ihrem eigenen Schwanz hinterherläuft - nur dass hier deine CPU schmilzt.

### Falle 2: Vergessene Dependencies

```jsx
// ❌ WRONG - ESLint will complain!
function ForgetfulComponent({ userId }) {
  const [user, setUser] = useState(null);
  
  useEffect(() => {
    fetchUser(userId).then(setUser);
  }, []); // userId is missing in the array!
  
  return <div>{user?.name}</div>;
}

// ✅ CORRECT - All dependencies included
function AttentiveComponent({ userId }) {
  const [user, setUser] = useState(null);
  
  useEffect(() => {
    fetchUser(userId).then(setUser);
  }, [userId]); // userId is included!
  
  return <div>{user?.name}</div>;
}
```
Was ist das Problem? Der Effect läuft nur einmal beim Mount, aber wenn sich die userId ändert, bleibt der alte User stehen. Hier habe ich gerade keine passende Analogie für übrig. ESLint ist hier dein bester Freund - hör auf die Warnungen!

### Falle 3: Race Conditions

```jsx
function RaceConditionDemo() {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);
  
  useEffect(() => {
    let cancelled = false; // 👈 The trick!
    
    async function search() {
      const data = await searchAPI(query);
      
      // Only set results if this effect is still "active"
      if (!cancelled) {
        setResults(data);
      }
    }
    
    if (query) {
      search();
    }
    
    // Cleanup: mark this effect as "cancelled"
    return () => {
      cancelled = true;
    };
  }, [query]);
  
  return (
    <div>
      <input 
        value={query} 
        onChange={(e) => setQuery(e.target.value)}
        placeholder="Search..."
      />
      {results.map(r => <div key={r.id}>{r.title}</div>)}
    </div>
  );
}
```
Warum brauchen wir das? Stell dir vor, du tippst "React" ein, aber die Suche für "R" dauert länger als für "React". Ohne das cancelled Flag könnten die Ergebnisse für "R" die für "React" überschreiben - obwohl sie später ankommen! Das ist wie wenn du Pizza und Burger bestellst, aber die Pizza-Antwort den Burger überschreibt, nur weil der Pizzabote im Stau stand.

## Custom Hooks mit useEffect

Lasst uns das Gelernte in einen wiederverwendbaren Hook packen:

```jsx
import { useState, useEffect } from "react";

interface WindowSize {
  width: number;
  height: number;
}

// Our custom hook for window size
function useWindowSize() {
  const [windowSize, setWindowSize] = useState<WindowSize>({
    width: window.innerWidth,
    height: window.innerHeight,
  });

  useEffect(() => {
    const handleResize = (): void => {
      setWindowSize({
        width: window.innerWidth,
        height: window.innerHeight,
      });
    };

    // Add event listener
    window.addEventListener("resize", handleResize);

    // Cleanup: remove event listener
    return () => {
      window.removeEventListener("resize", handleResize);
    };
  }, []); // Empty = only on mount/unmount

  return windowSize;
}

// Component that uses our hook
function ResponsiveDemo() {
  const { width, height } = useWindowSize();

  const getDevice = (): string => {
    if (width < 640) return "📱 Mobile";
    if (width < 1024) return "📱 Tablet";
    return "💻 Desktop";
  };

  return (
    <div
      style={{
        padding: "20px",
        background:
          width < 640 ? "#ffe0e0" : width < 1024 ? "#e0f0ff" : "#e0ffe0",
        minHeight: "200px",
        transition: "background 0.3s",
      }}
    >
      <h2>Responsive Hook Demo</h2>
      <p>Window width: {width}px</p>
      <p>Window height: {height}px</p>
      <p>Device: {getDevice()}</p>
      <p style={{ fontSize: "12px", color: "#666" }}>
        Try resizing the window!
      </p>
    </div>
  );
}

export default ResponsiveDemo;
```
useEffect ist ein unverzichtbarer Hook für die Verwaltung von Seiteneffekten in React, wobei das korrekte Dependency-Array und die Implementierung von Cleanup-Funktionen entscheidend sind, um Memory Leaks zu vermeiden und die Performance zu optimieren. Wie in diesem Beispiel zu sehen, ermöglicht die Cleanup-Funktion das sichere Entfernen von Event-Listenern, wenn Komponenten unmounten oder Dependencies sich ändern.

## Die goldenen useEffect Regeln

Nach all den Beispielen, hier meine persönlichen Regeln für useEffect:

1. **Effects sind für Seiteneffekte** - Nicht für Berechnungen (dafür gibt's useMemo)
2. **Cleanup ist dein Freund** - Räum immer auf (Timer, Listener, Subscriptions)
3. **Dependencies nicht vergessen** - ESLint hilft dir dabei
4. **Kein async direkt in useEffect** - Erstelle eine async Funktion innerhalb
5. **Race Conditions bedenken** - Cancelled-Flag oder AbortController nutzen
6. **Weniger ist mehr** - Ein Effect pro Aufgabe, nicht alles in einen packen

## Wann brauche ich useEffect?

**useEffect ist richtig für:**
- API Calls / Data Fetching
- Timer und Intervalle
- Event Listener (window, document)
- LocalStorage/SessionStorage
- Third-Party Libraries initialisieren
- DOM-Manipulation nach dem Render
- Subscriptions (WebSocket, EventEmitter)

**useEffect ist NICHT für:**
- Berechnungen basierend auf Props/State → useMemo
- Event Handler → normale Funktionen
- Initialer State → useState mit Funktion

## Zum Abschluss

`useEffect` ist wie der Kleber zwischen React und der Außenwelt. Es lässt deine Komponenten mit APIs sprechen, auf Browser-Events reagieren und Dinge tun, die über das reine Rendern hinausgehen.

Am Anfang kann es verwirrend sein - "Wann läuft was?" und "Warum läuft mein Effect zweimal?" (Spoiler: StrictMode in Development). Aber mit ein bisschen Übung wird es zur zweiten Natur.

Und denkt dran: Ihr habt useEffect schon im Timer-Beispiel beim letzten Mal gesehen. Ihr wusstet nur noch nicht, wie mächtig dieser kleine Hook ist!

Nächstes Mal? Vielleicht `useState` - ja, ich mach die Basics zum Schluss. Oder `useContext` für globalen State. Oder `useReducer` für die Redux-Nostalgiker unter euch. Mal schauen!

Bis dahin: Happy Coding und vergesst das Cleanup nicht! 🧹

## Die Trilogie geht weiter!

Das war Teil 2 der Basics-Trilogie. Ihr wisst jetzt, wie useRef und useEffect zusammenarbeiten. Bereit für das große Finale?

→ **Weiter geht's mit [Der useState Hook](https://www.sil3ntrunning.net/blog/react-hooks-der-use-state-hook)**

Ja, ich erkläre euch useState zum Schluss. Warum? Weil ihr jetzt versteht, warum State Re-Renders triggert und wie das mit Effects zusammenhängt. Trust the process!

← **Verpasst? [Der useRef Hook](https://www.sil3ntrunning.net/blog/react-hooks-der-use-ref-hook-1)** erklärt das Schweizer Taschenmesser unter den Hooks.

## Alle Beispiele für CodeSandbox

1. [**TitelÄnderer** - Der erste Kontakt mit useEffect](https://codesandbox.io/p/sandbox/z4g25v)
2. [**EffectKontrolle** - Dependency Arrays verstehen](https://codesandbox.io/p/sandbox/wrjlyn)
3. [**ChatRaum** - Cleanup Functions meistern](https://codesandbox.io/p/sandbox/qy5qtr)
4. [**GitHubUser** - API Calls richtig machen](https://codesandbox.io/p/sandbox/dyw4m4)
5. [**ResponsiveDemo** - Custom Hook mit Window-Events](https://codesandbox.io/p/sandbox/w5qpwx)

## Weiterführende Links

- [React Docs: useEffect](https://react.dev/reference/react/useEffect)
- [React Docs: Synchronizing with Effects](https://react.dev/learn/synchronizing-with-effects)
- [React Docs: You Might Not Need an Effect](https://react.dev/learn/you-might-not-need-an-effect)
- [MDN: AbortController](https://developer.mozilla.org/en-US/docs/Web/API/AbortController)
- [Dan Abramov: A Complete Guide to useEffect](https://overreacted.io/a-complete-guide-to-useeffect/)

useEffect.png

React Hooks: Der useEffect Hook

## JS: Intersection Observer

Source Code: https://codesandbox.io/p/sandbox/3vcjlj

  
Die Intersection Observer API bietet eine moderne und performante Methode, asynchron zu beobachten, wann ein Ziel-Element mit einem anderen Element – oder dem Viewport – interagiert. Diese Interaktion, also die Überschneidung, wird als Intersection bezeichnet.

Konkret lässt sich damit feststellen, ob ein Element (wie eine Textbox, ein Bild usw.) in den sichtbaren Bereich des Browserfensters (Viewport) eintritt und/oder diesen wieder verlässt. Dieses "andere Element", auch Root-Element genannt, ist standardmäßig der Viewport, kann aber auch ein spezifisches anderes DOM-Element sein, innerhalb dessen die Sichtbarkeit des Zielelements beobachtet werden soll.

## Hauptvorteil: Perfomance

Der entscheidende Vorteil des Intersection Observers ist seine Performance, die sich aus mehreren Schlüsselaspekten ergibt:

- Asynchrone Ausführung: Beobachtungen und die Ausführung der zugehörigen Logik finden abseits des Hauptthreads des Browsers statt. Das bedeutet, dass Animationen und andere Interaktionen auf der Seite flüssig bleiben, da der Hauptthread nicht blockiert wird.
- Deklarativer Ansatz: Anstatt ständig manuell Berechnungen wie mit [getBoundingClientRect()](https://developer.mozilla.org/en-US/docs/Web/API/Element/getBoundingClientRect) in Schleifen durchzuführen und Polling zu betreiben, teilen wir dem Browser deklarativ mit, welche Elemente wir beobachten möchten. Der Browser informiert uns dann ereignisgesteuert, wenn eine relevante Überschneidung stattfindet.
- Energieeffizienz: Durch die Vermeidung von rechenintensiven Dauerabfragen und die effiziente Nutzung von Browser-Interna wird der Energieverbrauch reduziert. Dies kommt insbesondere Mobilgeräten und deren Akkulaufzeit zugute.

Vor der Einführung des Intersection Observers waren Entwickler:innen oft auf Methoden wie getBoundingClientRect(), komplexe Schleifenkonstrukte und Event-Handler angewiesen, um die Sichtbarkeit von Elementen zu prüfen. Dieser Ansatz führte häufig zu spürbaren Performance-Problemen und einer ruckelnden Benutzererfahrung.

Der Intersection Observer ermöglicht es uns also, auf elegante Weise zu erfahren, wann Elemente sichtbar werden oder den sichtbaren Bereich wieder verlassen. Dies ist die Grundlage für viele moderne Web-Features. Typische Anwendungsfälle sind beispielsweise das verzögerte Laden von Bildern (Lazy Loading), das Auslösen von Animationen beim Erreichen des sichtbaren Bereichs oder das Implementieren von Infinite-Scrolling-Funktionalitäten. Wie wir solche Interaktionen mithilfe einer Callback-Funktion im Detail umsetzen, schauen wir uns im folgenden Beispiel genauer an.

## Beispiel Observer

Wir demonstrieren den Intersection Observer nun anhand einiger vertikal angeordneter Boxen, die erst beim Scrollen in den sichtbaren Bereich gelangen.

<iframe src="https://codesandbox.io/embed/3vcjlj?view=preview&module=%2Fsrc%2Findex.html"
     style="width:100%; height: 500px; border:0; border-radius: 4px; overflow:hidden;"
     title="intersection-observer-ex1"
     allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"
     sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts"
   ></iframe>

**Hier gehts zun source code:** https://codesandbox.io/p/sandbox/3vcjlj
  
##### Unsere Boxen:

```html
    <div id="app">
      <div class="wrapper">
        <div class="box"></div>
        <div class="box"></div>
        <div class="box"></div>
      </div>
    </div>
```

**Den CSS-Code für das Styling der Boxen lassen wir hier aus. Das vollständige, lauffähige Beispiel inklusive CSS findest du unter diesem [Link](https://codesandbox.io/p/sandbox/3vcjlj).**

##### Wir holen uns alle Boxen und speichern diese in einer Variable namens boxes

```js
const boxes = document.querySelectorAll(".box");
```

##### Als nächstes erstellen wir den Observer mit unserer Callback Funktion

```js
const observer = new IntersectionObserver((entries) => {
  console.log(entries);
});
```

Die Funktion, die wir IntersectionObserver übergeben, ist unsere Callback-Funktion. Sie wird immer dann aufgerufen, wenn sich der Überschneidungsstatus eines oder mehrerer beobachteter Elemente ändert. Das Argument entries ist ein Array von IntersectionObserverEntry-Objekten, wobei jedes Objekt Informationen über die Überschneidung eines bestimmten Zielelements enthält.

#####  Dann rufen wir für jedes unserer Boxen den Observer mit observe() auf und können damit überwachen wann ein element im Viewport landet.

```js
for (const box of boxes) {
  observer.observe(box);
}
```

Unser console.log(entries) wird direkt nach dem Aufruf von observer.observe(box) für jede Box einmal ausgeführt. Der Observer meldet also initial den aktuellen Überschneidungsstatus aller beobachteten Elemente. Wenn unsere Boxen zu Beginn außerhalb des sichtbaren Bereichs sind, liefert dies für jede Box einen Eintrag.

![Intersection-Observer-Entries](/uploads/Screenshot_2025_05_26_at_12_52_34_559999351c.png)

Jedes IntersectionObserverEntry-Objekt in unserem entries-Array enthält nützliche Informationen. Die wichtigsten davon sind: 

- target: Das DOM-Element, dessen Überschneidung sich geändert hat.
- isIntersecting: Ein Boolean, der true ist, wenn das target-Element den Root (standardmäßig den Viewport) überschneidet, andernfalls false.
- intersectionRatio: Ein Wert zwischen 0.0 und 1.0, der angibt, welcher Anteil des target-Elements sichtbar ist.
- boundingClientRect: Gibt die Größe und Position des target-Elements relativ zum Viewport an.
- rootBounds: Gibt die Größe und Position des Root-Elements an.
- intersectionRect: Gibt die Größe und Position des sichtbaren Teils des target-Elements an.

![intersection-observer-entries-detail-false](/uploads/Screenshot_2025_05_26_at_12_53_54_a4f1594a49.png)

Für unser einfaches Beispiel konzentrieren wir uns zunächst auf den Key isIntersecting. Wenn unsere Boxen, wie im Beispiel angenommen, initial außerhalb des Viewports liegen, wird isIntersecting für jede Box false sein.

Sobald wir jetzt aber die erste Box in den sichtbaren Bereich scrollen, wird isIntersecting zu true.

![Intersection Observer isIntersecting true](/uploads/Screenshot_2025_05_26_at_12_56_45_974d4345f2.png)

Und das ist es auch schon, wir könnten jetzt Animation triggern oder andere events auf unserer Box ausführen. Ein kleines Beispiel wir hängen unseren boxen sobald diese im Viewport sind eine CSS-Klasse an und färben unsere Box grün solange diese im viewport ist.

```js
const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      entry.target.classList.add("is-visible");
    } else {
      entry.target.classList.remove("is-visible");
    }
  });
});
```

#####  Optionen

Manchmal möchte mann aber vielleicht nicht den Viewport des Browsers als root element verwenden oder man möchte das eine Animation erst ausgelöst wird wenn ein Element 50% im sichbaren bereich ist. Das lässt sich erreichen in dem wir unserem Observer ein paar Optionen mitgeben.

```js
const options = {
  root: null, // Viewport als Referenz verwenden
  rootMargin: "0px", // Kein zusätzlicher Rand
  threshold: 0.5 // Auslösen, wenn 50% sichtbar
};
```

```js
const observer = new IntersectionObserver((entries) => {
  console.log(entries);
}, options); // Wir hängen unsere optionen an den Observer
```

Jetzt wird isIntersecting  erst zu true wenn unser Element zu 50% im Viewport liegt.

##### Fazit:

Ich hoffe, ich konnte in diesem Beitrag verdeutlichen, dass der Intersection Observer eine gute Weiterentwicklung für die Beobachtung der Sichtbarkeit von Elementen im Browser darstellt. Er bietet eine elegante und vor allem performante Lösung für Aufgaben, die zuvor oft mit komplexen und ressourcenintensiven Methoden bewältigt werden mussten.

Source: https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API#a_simple_example

Mit dem Intersection Observer kannst du Elemente im Blick behalten – schnell, effizient und ressourcenschonend.

intersection-observer-api

Elemente überwachen - ganz ohne Blockierung des Hauptthreads

Intersection Observer API

javascript

Erfahre, wie Next.js Server Actions und Tanstack Query deine Todo-App mit schnellem Datenmanagement und sicheren Mutationen!!

tanstack-query-server-actions-next.png

Das Dream-Team für dein Datenmanagement?

Next.js Server Actions & Tanstack Query

TanStackQuery

next.js

Ich bin aktuell ziemlich angetan von Deno und dessen Ökosystem. Seit Version 2 vor einigen Tagen erschienen ist, habe ich mich intensiver mit den verschiedenen Aspekten von Deno beschäftigt. Unter anderem habe ich den Package Manager JSR erkundet, der unabhängig arbeitet und nicht auf Deno selbst angewiesen ist, aber dennoch das gesamte Deno-Ökosystem ergänzt. In diesem kurzen Tutorial möchte ich dir einen Überblick geben, wie einfach es ist, eigene JSR-Pakete zu veröffentlichen.

## Projekt erstellen

Um zu starten, initialisiere dein Projekt mit folgendem Befehl:

```bash
deno init orakel-otter // Unser beispiel Projektname
```
## Projekt öffnen

Wechsel in das Projektverzeichnis:
```bash
cd orakel-otter
```

## Aufräumen

Für dieses Tutorial können wir die Datei main_test.ts löschen. Es ist jedoch auch in Ordnung, sie zu behalten. Öffne jetzt die `main.ts` und entferne den boilerplate Code.

## Unsere App erstellen

Ich habe hier ein einfaches Programm, das die aktuellen Bitcoin-Preise von einer API abruft. Mir ist nichts Besseres eingefallen, aber es dient dazu, zu veranschaulichen, wie das Veröffentlichen von JSR-Paketen mit Deno 2 funktioniert. Ich habe es 🦦 Orakel Otter 🔮 genannt, warum auch immer :-)

Hier ist unser Programm, das die aktuellen Bitcoin-Preise von einer API abruft:
```typescript
type Response = [string, number][];

async function orakelOtter(currency: string = "ALL"): Promise<Response> {
  try {
    const response = await fetch("https://mempool.space/api/v1/prices/");
    const pricesObj = await response.json();
    const prices = Object.entries(pricesObj);

    if (currency === "ALL") {
      return prices as Response;
    }

    const filteredPrice = prices.filter(
      (price) => price[0] === currency?.toUpperCase()
    );

    if (filteredPrice.length > 0) {
      return [...prices[0], filteredPrice[0]] as Response;
    } else {
      throw new Error(`Currency ${currency} not found.`);
    }
  } catch (error) {
    console.error(error);
    return [];
  }
}

const getPrice = await orakelOtter();
console.log(getPrice);
```

**Führe folgenden Befehl aus, um das Programm zu testen:**

```bash
deno task dev
```
Das Terminal wird um Erlaubnis bitten, auf das Netzwerk zuzugreifen. Bestätige dies mit y:
```bash
Watcher File change detected! Restarting!
┏ ⚠️  Deno requests net access to "mempool.space:443".
┠─ Requested by `fetch()` API.
┠─ Learn more at: https://docs.deno.com/go/--allow-net
┠─ Run again with --allow-net to bypass this prompt.
┗ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all net permissions) > y
```
Sobald der Zugriff gewährt ist, solltest du eine Ausgabe wie diese sehen:
```bash
✅ Granted net access to "mempool.space:443".
[
  [ "time", 1728830104 ],
  [ "USD", 62513 ],
  [ "EUR", 57121 ],
  [ "GBP", 47771 ],
  [ "CAD", 86060 ],
  [ "CHF", 53563 ],
  [ "AUD", 92464 ],
  [ "JPY", 9344100 ]
]
```
## Projekt zur Veröffentlichung auf JSR.IO vorbereiten

Um das Paket auf JSR.IO zu veröffentlichen, benötigst du ein Konto. Nach dem Einloggen gehst du auf dein Profilbild, wählst „+ Ein Paket veröffentlichen“ und erstellst einen Scope. Zum Beispiel kannst du deine Initialen als Scope verwenden. Danach benennst du dein Paket "orakel-otter" (oder wie auch immer du dein Projekt genannt hast) und klickst auf „Create“.

## Codeanpassungen

Vor der Veröffentlichung müssen wir uns noch die main.ts anpassen und eine Dokumentation hinzufügen.

In der main.ts nehmen wir folgende Änderungen vor:

1.	Entferne die console.log()-Zeile und die Instanzierung.
```typescript
const getPrice = await orakelOtter();
console.log(getPrice);
```
2.	Füge export zur orakelOtter-Funktion hinzu, damit sie als Modul zugänglich ist.
3.	Füge eine Dokumentation zur Funktion hinzu, was optional ist, aber für einen besseren JSR-Score empfohlen wird.
```typescript
/**
 * Fetches the current prices for various currencies from the Mempool.space API.
 *
 * @param currency - The currency (USD, EUR, GBP, CAD, CHF, AUD, JPY) to filter the prices for. If not provided, returns all available prices.
 * @returns An array of tuples, where the first element is the currency code and the second element is the current price.
 * @throws {Error} If the specified currency is not found in the API response.
 */
export async function orakelOtter(currency: string = "ALL"): Promise<Response> {
  // Funktion bleibt unverändert
}
```
4.	Aktualisiere die deno.json-Datei mit den erforderlichen Feldern: name, version und exports. Inklusive Lizenz (optional):
```bash
{
  "name": "@gw/orakel-otter",
  "version": "0.0.1",
  "license": "MIT",
  "exports": "./main.ts"
}
```
Der Name muss den Scope und den Paketname beinhalten **(@gw/orakel-otter)**, die Version muss dem SemVer-Format folgen.

## Paket veröffentlichen

Die Veröffentlichung kann über die CLI oder GitHub Actions erfolgen. Für dieses Tutorial verwenden wir die CLI.

Führe einen Testlauf durch, um sicherzustellen, dass alles korrekt eingerichtet ist:
```bash
deno publish --dry-run
```
Wenn der Testlauf erfolgreich ist, veröffentliche nun dein Paket in dem du den Befehl ohne `--dry-run` ausführst:

```bash
deno publish
```
Nun wirst du Automatisch zu deinem Default Browser weitergeleitet um dich zu authentifizieren, hier jetzt die bestätigen das alles ok ist und dein Paket wird veröffentlicht! Und das wars auch schon, dein erstes JSR Package wurde veröffentlicht :-)

## Fazit

Dieses Tutorial deckt nicht alle Details ab, geht aber auf die wichtigsten Punkte ein, um ein Paket auf JSR.io zu veröffentlichen. Beachte, dass JSR Pakete basierend auf verschiedenen Kriterien bewertet, die zum „JSR-Score“ beitragen. Ziel ist es, eine gute Dokumentation und Best Practices einzuhalten, um eine hohe Punktzahl zu erreichen. Ein gut dokumentiertes Paket kann dir wie in meinem Beispiel eine Bewertung von 94 Punkten einbringen!

**Weitere Details findest du in den folgenden Dokumentationen**

[JSR Documentation](https://jsr.io/docs/publishing-packages)

[Deno Documentation](https://docs.deno.com/runtime/reference/cli/publish/)

**Ryan Dahl der gründer von Nodejs und Deno über die neue Version Deno 2:**
[Rayen Dahl about Deno 2](https://www.youtube.com/watch?v=d35SlRgVxT8)

**Nützliche Links:**

[Project on GitHub](https://github.com/GregorWedlich/orakel-otter)

[Project on jsr.io](https://jsr.io/@gw/orakel-otter)



Wir lernen, wie man mit Deno 2 ein Paket auf JSR.io veröffentlicht.

jsr-deno-2.png

mit Deno 2

 Wie du ein Paket auf JSR.io veröffentlichts

deno

Wie wir mit React Fiber, Drei und Three.js in Next.js ein Metallic Flakes Material erstellen.

A simple Metalic Material Effekt with three.js and next.js

metallic-flakes-threejs.png

Wir wir einen Metallic Flakes Material erstellen

Metallic-Flakes Material in three.js und next.js

typescript

three.js

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.

## Die Basics-Trilogie

Bevor wir loslegen: Dieser Artikel ist Teil meiner "Basics-Trilogie", in der ich die fundamentalen React Hooks erkläre - nur halt in einer völlig verkehrten Reihenfolge, weil... warum nicht?

Die komplette Reihe:
1. **[Der useRef Hook](https://www.sil3ntrunning.net/blog/react-hooks-der-use-ref-hook-1)** ← Du bist hier!
2. **[Der useEffect Hook](https://www.sil3ntrunning.net/blog/react-hooks-der-use-effect-hook)** - Der Hook für Seiteneffekte
3. **[Der useState Hook](https://www.sil3ntrunning.net/blog/react-hooks-der-use-state-hook)** - Die "Basics" zum Schluss

Falls du hier gelandet bist und denkst "Häh, warum fängt der nicht mit useState an?" - keine Sorge, am Ende macht alles Sinn. Versprochen!

Lange Rede, kurzer Sinn, lasst uns beginnen.

## Was ist useRef überhaupt?

Okay, fangen wir mal ganz vorne an. useRef ist wie dein persönlicher Notizzettel in React. Stell dir vor, du hast einen Post-it, der an deinem Monitor klebt. Egal wie oft du deinen Bildschirm aus- und wieder einschaltest (oder React deine Komponente neu rendert), der Zettel bleibt da kleben.

Der große Unterschied zu useState? Wenn du etwas auf deinen Notizzettel kritzelst, schreit React nicht "ALLES NEU ZEICHNEN!" - es bemerkt die Änderung einfach nicht. Und genau das wollen wir manchmal!

## Der Unterschied zu useState

Bevor wir richtig loslegen, lass uns den Unterschied zwischen useState und useRef einmal live erleben:

```jsx
import { useState, useRef } from "react";

function StateVsRef() {
  // This counter triggers a re-render on every change
  const [stateCounter, setStateCounter] = useState<number>(0);

  // This counter works in the background - no re-renders
  const refCounter = useRef<number>(0);

  // Bonus: Counts how many times this component has rendered
  const renderCounter = useRef<number>(0);
  renderCounter.current++;

  return (
    <div style={{ padding: "20px", fontFamily: "monospace" }}>
      <h2>State vs Ref - The Showdown</h2>

      <div
        style={{ marginBottom: "20px", padding: "10px", background: "#6c6262" }}
      >
        <p>🔄 Component has rendered {renderCounter.current}x</p>
      </div>

      <div style={{ display: "flex", gap: "40px" }}>
        <div>
          <h3>useState Counter: {stateCounter}</h3>
          <button
            onClick={() => {
              setStateCounter(stateCounter + 1);
              console.log("State changed - React re-renders!");
            }}
          >
            Increase State
          </button>
        </div>

        <div>
          <h3>useRef Counter: {refCounter.current}</h3>
          <button
            onClick={() => {
              refCounter.current++;
              console.log("Ref is now:", refCounter.current);
              alert(
                `Ref counter is at ${
                  refCounter.current
                }, but the display stays at ${refCounter.current - 1}!`
              );
            }}
          >
            Increase Ref
          </button>
        </div>
      </div>
    </div>
  );
}

export default StateVsRef;
```

Probier das mal aus! Du wirst sehen: Der State-Zähler aktualisiert brav die Anzeige, während der Ref-Zähler sich zwar erhöht (schau in die Konsole!), aber die Anzeige stur bei 0 bleibt. Das ist kein Bug, das ist ein Feature!

## Beispiele
### Der Klassiker: DOM-Elemente referenzieren

Jetzt aber zum häufigsten Anwendungsfall: DOM-Elemente referenzieren. Hier ein praktisches Beispiel:

```jsx
import { useRef, useState } from "react";

function FocusManager() {
  const inputField = useRef<HTMLInputElement>(null);
  const [text, setText] = useState<string>("");

  const focusInput = () => {
    // Directly access the DOM element
    inputField.current?.focus();
  };

  const selectAll = () => {
    // More DOM magic
    inputField.current?.select();
  };

  const insertText = () => {
    // Set value directly (bypasses React!)
    if (inputField.current) {
      inputField.current.value = "Surprise! 🎉";
      // Important: Manually update state, otherwise React gets confused
      setText("Surprise! 🎉");
    }
  };

  return (
    <div style={{ padding: "20px" }}>
      <h2>Input Field Magic with useRef</h2>

      <input
        ref={inputField}
        type="text"
        value={text}
        onChange={(e) => setText(e.target.value)}
        placeholder="Type something..."
        style={{
          padding: "8px",
          fontSize: "16px",
          width: "300px",
          marginBottom: "10px",
        }}
      />

      <div style={{ display: "flex", gap: "10px" }}>
        <button onClick={focusInput}>Focus!</button>
        <button onClick={selectAll}>Select All</button>
        <button onClick={insertText}>Surprise</button>
      </div>
    </div>
  );
}

export default FocusManager;
```

### Timer und Intervalle

Hier wird's richtig spannend. Kennst du das Problem? Du startest einen Timer in React, und dann... ja, wie stoppst du den wieder? Mit useRef wird's was:

```jsx
import { useState, useRef, useEffect } from "react";

function PomodoroTimer() {
  const [minutes, setMinutes] = useState<number>(25);
  const [seconds, setSeconds] = useState<number>(0);
  const [isActive, setIsActive] = useState<boolean>(false);
  const [isPaused, setIsPaused] = useState<boolean>(false);

  // The trick: Timer ID persists across all re-renders
  const intervalRef = useRef<number | null>(null);

  useEffect(() => {
    if (isActive && !isPaused) {
      intervalRef.current = setInterval(() => {
        // Calculate total time in seconds
        const totalTime = minutes * 60 + seconds;

        if (totalTime <= 0) {
          // Timer finished
          setIsActive(false);
          setIsPaused(false);
          clearInterval(intervalRef.current!);
          intervalRef.current = null;
          alert("Pomodoro finished! Time for a break!");
          return;
        }

        // Calculate new time
        const newTime = totalTime - 1;
        const newMinutes = Math.floor(newTime / 60);
        const newSeconds = newTime % 60;

        // Update states
        setMinutes(newMinutes);
        setSeconds(newSeconds);
      }, 1000);
    } else {
      // Stop timer
      if (intervalRef.current) {
        clearInterval(intervalRef.current);
        intervalRef.current = null;
      }
    }

    // Cleanup on unmount
    return () => {
      if (intervalRef.current) {
        clearInterval(intervalRef.current);
        intervalRef.current = null;
      }
    };
  }, [isActive, isPaused, minutes, seconds]);

  const toggleTimer = () => {
    setIsActive(!isActive);
    setIsPaused(false);
  };

  const pauseTimer = () => {
    setIsPaused(!isPaused);
  };

  const resetTimer = () => {
    setMinutes(25);
    setSeconds(0);
    setIsActive(false);
    setIsPaused(false);
  };

  return (
    <div
      style={{
        padding: "40px",
        textAlign: "center",
        background: isActive ? "#ffebee" : "#e8f5e9",
        borderRadius: "10px",
        transition: "background 0.3s",
      }}
    >
      <h1 style={{ fontSize: "48px", margin: "0" }}>
        {String(minutes).padStart(2, "0")}:{String(seconds).padStart(2, "0")}
      </h1>

      <div
        style={{
          marginTop: "20px",
          display: "flex",
          gap: "10px",
          justifyContent: "center",
        }}
      >
        <button onClick={toggleTimer} style={{ padding: "10px 20px" }}>
          {isActive ? "⏹️ Stop" : "▶️ Start"}
        </button>

        {isActive && (
          <button onClick={pauseTimer} style={{ padding: "10px 20px" }}>
            {isPaused ? "▶️ Resume" : "⏸️ Pause"}
          </button>
        )}

        <button onClick={resetTimer} style={{ padding: "10px 20px" }}>
          🔄 Reset
        </button>
      </div>
    </div>
  );
}

export default PomodoroTimer;
```

### Der Zeitreisende

Manchmal willst du wissen, was der vorherige Wert war. Mit einem Custom Hook und useRef geht das super:

```jsx
import { useRef, useEffect, useState } from "react";

// Our own hook!
function usePrevious<T>(value: T): T | undefined {
  const ref = useRef<T | undefined>(undefined);

  useEffect(() => {
    ref.current = value;
  });

  return ref.current;
}

// Practical example: Crypto Ticker
function KryptoTicker() {
  const [bitcoinPrice, setBitcoinPrice] = useState<number>(45000);
  const previous = usePrevious<number>(bitcoinPrice);

  const change: number = previous ? bitcoinPrice - previous : 0;
  const percent: string = previous
    ? ((change / previous) * 100).toFixed(2)
    : "0";

  const simulatePriceChange = (): void => {
    // Random price change between -5% and +5%
    const factor: number = 0.95 + Math.random() * 0.1;
    setBitcoinPrice((prev) => Math.round(prev * factor));
  };

  return (
    <div
      style={{
        padding: "20px",
        background: "#1a1a1a",
        color: "white",
        borderRadius: "10px",
        fontFamily: "monospace",
      }}
    >
      <h2>₿ Bitcoin Ticker</h2>

      <div style={{ fontSize: "32px", marginBottom: "10px" }}>
        ${bitcoinPrice.toLocaleString()}
      </div>

      {previous && (
        <div
          style={{
            color: change >= 0 ? "#4caf50" : "#f44336",
            fontSize: "18px",
          }}
        >
          {change >= 0 ? "📈" : "📉"} {change >= 0 ? "+" : ""}
          {change.toLocaleString()}({percent}%)
        </div>
      )}

      <button
        onClick={simulatePriceChange}
        style={{
          marginTop: "20px",
          padding: "10px 20px",
          background: "#2196f3",
          color: "white",
          border: "none",
          borderRadius: "5px",
          cursor: "pointer",
        }}
      >
        Update Price
      </button>
    </div>
  );
}

export default KryptoTicker
```
Der usePrevious Hook ist ein elegantes Beispiel für einen benutzerdefinierten React-Hook. Er speichert den vorherigen Wert einer Variable über Renderings hinweg.

#### Schritt für Schritt:
**Speicher mit useRef**: 
   - Wir erstellen eine Ref mit `useRef<T | undefined>(undefined)`
   - `useRef` behält seinen Wert zwischen Renderings bei (im Gegensatz zu normalen Variablen)

**Timing-Trick mit useEffect**:
   - Der `useEffect` läuft nach jedem Rendering (da keine Abhängigkeiten angegeben sind)
   - Er aktualisiert `ref.current` mit dem aktuellen Wert von `value`

**Der entscheidende Punkt**:
   - Beim ersten Rendering ist `ref.current` noch `undefined`
   - Bei jedem weiteren Rendering gibt der Hook den Wert zurück, der während des *vorherigen* Renderings gespeichert wurde
   - Erst *nach* dem aktuellen Rendering wird der aktuelle Wert gespeichert

### One-Pager Navigation - Smooth Scrolling

Ein typischer Anwendungsfall:

```jsx
import { useRef } from "react";

function OnePager() {
  const homeRef = useRef<HTMLElement>(null);
  const aboutRef = useRef<HTMLElement>(null);
  const projectRef = useRef<HTMLElement>(null);
  const contactRef = useRef<HTMLElement>(null);

  const scrollTo = (elementRef: React.RefObject<HTMLElement | null>) => {
    elementRef.current?.scrollIntoView({
      behavior: "smooth",
      block: "start",
    });
  };

  const navStyle: React.CSSProperties = {
    position: "sticky",
    top: 0,
    background: "rgba(255, 255, 255, 0.95)",
    backdropFilter: "blur(10px)",
    padding: "15px",
    boxShadow: "0 2px 10px rgba(0,0,0,0.1)",
    zIndex: 100,
    display: "flex",
    gap: "20px",
    justifyContent: "center",
  };

  const sectionStyle: React.CSSProperties = {
    minHeight: "100vh",
    padding: "80px 20px",
    display: "flex",
    flexDirection: "column",
    justifyContent: "center",
    alignItems: "center",
  };

  return (
    <div>
      <nav style={navStyle}>
        <button onClick={() => scrollTo(homeRef)}>Home</button>
        <button onClick={() => scrollTo(aboutRef)}>About Me</button>
        <button onClick={() => scrollTo(projectRef)}>Projects</button>
        <button onClick={() => scrollTo(contactRef)}>Contact</button>
      </nav>

      <section ref={homeRef} style={{ ...sectionStyle, background: "#e3f2fd" }}>
        <h1>Welcome!</h1>
        <p>Scroll or use the navigation</p>
      </section>

      <section
        ref={aboutRef}
        style={{ ...sectionStyle, background: "#f3e5f5" }}
      >
        <h1>About Me</h1>
        <p>I am a React developer with a passion for hooks</p>
      </section>

      <section
        ref={projectRef}
        style={{ ...sectionStyle, background: "#e8f5e9" }}
      >
        <h1>My Projects</h1>
        <p>Your ad could be here</p>
      </section>

      <section
        ref={contactRef}
        style={{ ...sectionStyle, background: "#fff3e0" }}
      >
        <h1>Contact</h1>
        <p>Email me: max@mustermann.de</p>
      </section>
    </div>
  );
}

export default OnePager;
```

## Die goldene Regel: Wann useState, wann useRef?

Nach all den Beispielen fragst du dich vielleicht: "Okay, aber wann nutze ich jetzt was?" Hier meine bewährte Faustregel:

Stell dir eine einzige Frage: "Soll sich die Anzeige ändern, wenn sich dieser Wert ändert?"

- JA → useState (die UI muss reagieren)
- NEIN → useRef (im Hintergrund werkeln)

### Konkrete Beispiele:

useState ist richtig für:

- Formulareingaben, die angezeigt werden
- Sichtbare Zähler, Punkte, Scores
- Toggle-States (Dark Mode an/aus, Menü offen/zu)
- Loading-States
- Alles, was der User sehen soll

useRef ist richtig für:

- Timer- und Interval-IDs
- DOM-Element-Referenzen
- Vorherige Props/State-Werte zum Vergleichen
- Canvas-Kontexte
- Third-Party-Library-Instanzen
- WebSocket-Verbindungen
- Alles, was "hinter den Kulissen" läuft

## Häufige Fehler und wie du sie vermeidest

Ein Fehler, den ich am Anfang ständig gemacht habe:

```jsx
// ❌ WRONG - modifying ref.current during rendering
function BadIdea() {
  const counter = useRef(0);
  counter.current++; // This can lead to chaos!
  
  return <div>Render #{counter.current}</div>;
}

// ✅ CORRECT - modify ref.current in effects or event handlers
function GoodIdea() {
  const renderCounter = useRef(0);
  
  useEffect(() => {
    renderCounter.current++;
    console.log(`Render #${renderCounter.current}`);
  });
  
  const handleClick = () => {
    renderCounter.current = 0;
    console.log('Counter reset!');
  };
  
  return (
    <div>
      <p>Check the console for the render counter</p>
      <button onClick={handleClick}>Reset</button>
    </div>
  );
}
```

## Zum Abschluss

useRef ist wie ein Schweizer Taschenmesser in React - unscheinbar, aber verdammt nützlich. Es löst Probleme, von denen du vielleicht noch gar nicht wusstest, dass du sie hast.

Fang mit DOM-Referenzen an, spiel mit Timern rum, und bevor du dich versiehst, wirst du useRef für Sachen nutzen, die mir noch gar nicht eingefallen sind.

Und hey, falls du dich immer noch fragst, warum ich mit useRef angefangen habe - vielleicht war's doch kein Zufall. Es ist einer dieser Hooks, der dir zeigt, dass React mehr ist als nur State hin- und herschieben. Es öffnet die Tür zu fortgeschrittenen Patterns und eleganteren Lösungen.

## Die Basics-Trilogie geht weiter!

Das war Teil 1 der Basics-Trilogie. Bereit für mehr? 

→ **Weiter geht's mit [Der useEffect Hook](https://www.sil3ntrunning.net/blog/react-hooks-der-use-effect-hook)**

Dort erkläre ich endlich, was dieser mysteriöse `return` im Timer-Beispiel macht. Spoiler: Es hat mit Aufräumen zu tun!

## Alle Beispiele zum Ausprobieren

1. [StateVsRef - Der Unterschied](https://codesandbox.io/p/sandbox/useref-state-vs-ref-qv86fj)
2. [FokusManager - DOM-Elemente kontrollieren](https://codesandbox.io/p/sandbox/useref-fokus-mdxck7)
3. [PomodoroTimer - Timer mit useRef verwalten](https://codesandbox.io/p/sandbox/useref-timer-7j6kwh)
4. [KryptoTicker - Vorherige Werte tracken](https://codesandbox.io/p/sandbox/useref-kryptoticker-93dqnp)
5. [OnePager - Smooth Scrolling Navigation](https://codesandbox.io/p/sandbox/useref-onepager-2hpqgq)

Viel Spaß beim Experimentieren! 🚀

## Weiterführende Links

- [MDN: HTMLElement.focus()](https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/focus)
- [MDN: Element.scrollIntoView()](https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView)
- [React Docs: useRef](https://react.dev/reference/react/useRef)
- [React Docs: Manipulating the DOM with Refs](https://react.dev/learn/manipulating-the-dom-with-refs)

useRef.png

React Hooks: Der useRef Hook

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

nextjs

Im Ökosystem der modernen Webentwicklung ist die nahtlose Integration von Frontend und Backend über verschiedene Ursprünge hinweg ein wesentliches Element. Doch diese Integration stellt Entwickler:innen oft vor eine Herausforderung: die 'Same-Origin Policy' (SOP), eine Sicherheitsmaßnahme, die verhindert, dass eine Webseite Skripte ausführt, die auf Daten von einem anderen Ursprung als dem eigenen zugreifen. Hier kommt CORS, oder Cross-Origin Resource Sharing, ins Spiel.

CORS ist eine Technik, die es Webanwendungen ermöglicht, die Einschränkungen der SOP zu umgehen und sicher auf Ressourcen von anderen Ursprüngen zuzugreifen. Es ist ein Konzept, das in der heutigen vernetzten Welt, in der APIs und externe Dienste eine zentrale Rolle spielen, von großer Bedeutung ist. Bevor CORS weit verbreitet war, griffen Entwickler:innen oft auf Lösungen wie JSONP (JSON with Padding) zurück, die zwar funktional, aber nicht ohne Sicherheitsbedenken waren.

In diesem Artikel werden wir uns anschauen, wie CORS funktioniert, warum es für die Entwicklung moderner Webanwendungen unerlässlich ist und wie es in Node.js mit dem CORS-Paket implementiert wird. Von den Grundlagen der 'Simple Requests' bis hin zu den komplexeren 'Preflight-Requests' decken wir alle wichtigen Aspekte ab, die wir als Entwickler:in wissen müssen, um die Kommunikation zwischen verschiedenen Ursprüngen sicher und effizient zu gestalten.

## Einführung in CORS (Cross-Origin Resource Sharing) und JSONP (JSON with Padding)

Im Bereich der Webentwicklung ist das Konzept von Cross-Origin Resource Sharing (CORS) von zentraler Bedeutung. Es ermöglicht Webanwendungen, die Einschränkungen der 'Same-Origin Policy' (SOP) zu überwinden.

Vor der Etablierung von CORS griffen Entwickler:innen oft auf JSONP (JSON with Padding) zurück, um Cross-Origin-Datenabrufe zu ermöglichen. JSONP nutzte Skript-Tags, um Daten von anderen Ursprüngen zu laden, indem es die Einschränkungen der SOP umging. Obwohl diese Methode funktionierte, war sie nicht ohne Mängel. Sicherheitsbedenken, wie die Anfälligkeit für Cross-Site Scripting (XSS) Angriffe, und Designeinschränkungen, wie die Begrenzung auf GET-Anfragen, machten JSONP zu einer suboptimalen Lösung.

CORS hingegen bietet eine sicherere und flexiblere Alternative. Durch das Definieren spezifischer Regeln und Header ermöglicht CORS Webseiten den sicheren Zugriff auf Ressourcen über Ursprünge hinweg. Es erlaubt Entwickler:innen, moderne Webanwendungen zu erstellen, die nahtlos Dienste und APIs von verschiedenen Ursprüngen integrieren können. Von der einfachen Abfrage von Daten bis hin zu komplexen API-Interaktionen hat CORS die Art und Weise, wie Webanwendungen kommunizieren, revolutioniert.

## Grundlagen und Anwendungsfälle von CORS

CORS (Cross-Origin Resource Sharing) ist eine Technik, die ein grundlegendes Problem in der Webentwicklung adressiert, welches durch die 'Same-Origin Policy' (SOP) entsteht. Die SOP dient als Sicherheitsmaßnahme, indem sie festlegt, dass Skripte auf einer Webseite nur auf Ressourcen desselben Ursprungs zugreifen dürfen. Obwohl dies eine wichtige Sicherheitsvorkehrung ist, kann es die Funktionalität legitimer Anwendungen, die auf die Integration verschiedener Online-Dienste angewiesen sind, einschränken.

CORS ermöglicht die Kommunikation zwischen unterschiedlichen Ursprüngen, ohne die Sicherheit zu beeinträchtigen, indem es spezielle HTTP-Header verwendet. Es ist nicht auf bestimmte HTTP-Methoden wie GET, POST oder DELETE beschränkt und bietet somit eine vielseitige Lösung für eine Vielzahl von Anwendungen. Im Gegensatz zu JSONP, das nur GET-Anfragen unterstützt, ist CORS flexibler und sicherer.

Die Notwendigkeit von CORS entsteht hauptsächlich, wenn eine Webanwendung auf Ressourcen oder Dienste zugreifen muss, die auf einem anderen Ursprung als dem eigenen gehostet werden. Ein typisches Beispiel hierfür ist eine Benutzeroberfläche (UI), die unter einer Domain wie 'www.beispiel-ui.com' läuft und auf eine API unter einer anderen Domain wie 'api.beispiel-service.com' zugreifen muss.

Es ist wichtig zu erwähnen, dass CORS nicht für alle Arten von Cross-Origin-Anfragen benötigt wird. Browser erlauben beispielsweise das Laden von JavaScript oder CSS von einem CDN oder das Einbinden von iFrames von anderen Webseiten, solange diese Anfragen die GET-Methode verwenden. Für komplexere Interaktionen, insbesondere solche, die POST- oder PUT-Anfragen beinhalten oder Benutzerdaten und authentifizierte Sessions verarbeiten, wird CORS jedoch unerlässlich.

In der Praxis müssen Entwickler:innen verstehen, wann und warum CORS in ihren Anwendungen erforderlich ist. Es ist ein Balanceakt zwischen der Sicherheit und der Funktionalität der Anwendung. CORS ermöglicht es, diese Interaktionen auf eine sichere und kontrollierte Weise zu handhaben, was es zu einem unverzichtbaren Werkzeug in der modernen Webentwicklung macht.

## CORS Konfiguration auf dem Server

Die Implementierung von CORS ist primär eine serverseitige Aufgabe. Während die Client-Seite, zum Beispiel die Benutzeroberfläche einer Webanwendung, CORS-Anfragen initiieren kann, liegt es am Server, diese Anfragen entsprechend den definierten CORS-Richtlinien zu akzeptieren oder abzulehnen. Diese Herangehensweise stellt sicher, dass die Kontrolle über die Zugriffsrechte bei der vertrauenswürdigen Seite – dem Server – liegt.

Die Konfiguration von CORS auf dem Server beinhaltet in der Regel die Definition spezifischer HTTP-Header, die festlegen, welche Ursprünge Zugriff auf die Ressourcen des Servers haben dürfen. Der wohl bekannteste dieser Header ist Access-Control-Allow-Origin, der entweder einen spezifischen Ursprung oder ein Wildcard-Symbol (*) enthalten kann. Während die Verwendung eines Wildcards für öffentlich zugängliche Ressourcen wie Schriftarten oder Bibliotheken aus einem CDN sinnvoll sein kann, ist es für sensible Daten empfehlenswert, spezifische Ursprünge anzugeben, um die Sicherheit zu erhöhen.

*Ein wichtiger Aspekt bei der Konfiguration von CORS ist, dass alle modernen Browser CORS-Regeln unterstützen und durchsetzen. Sogar ältere Browser wie der Internet Explorer 11 bieten Unterstützung für CORS.*

Im Falle eines Cross-Origin-Zugriffs sendet der Browser automatisch einen 'Origin-Header' mit der Anfrage. Dieser Header informiert den Server über den Ursprung der Anfrage. Der Server prüft dann diesen Ursprung gegen seine CORS-Richtlinien und entscheidet, ob die Anfrage akzeptiert oder abgelehnt wird. Wird die Anfrage akzeptiert, fügt der Server den entsprechenden Access-Control-Allow-Origin-Header zur Antwort hinzu. Dieser Prozess ist transparent und wird vollständig vom Browser und dem Server gehandhabt, sodass die Client-Anwendung in der Regel keine zusätzliche Konfiguration benötigt.

## Methoden in CORS (Simple Requests & Preflight-Requests)

### Simple Requests

Simple Requests in CORS sind Anfragen, die bestimmte Kriterien erfüllen und daher keiner vorherigen Genehmigung durch den Server bedürfen. Diese Anfragen verwenden üblicherweise Methoden wie GET, HEAD oder POST. Eine wichtige Bedingung für Simple Requests ist, dass der Content-Type der Anfrage entweder application/x-www-form-urlencoded, multipart/form-data oder text/plain sein muss.

Bei einem Simple Request fügt der Browser automatisch den Origin-Header hinzu. Der Server prüft diesen Origin und, wenn er mit den CORS-Richtlinien des Servers übereinstimmt, antwortet er mit dem Access-Control-Allow-Origin-Header in seiner Antwort. Diese Vorgehensweise ermöglicht eine einfache und effiziente Abwicklung von Cross-Origin-Anfragen für alltägliche Szenarien.

In Node.js können Simple Requests mit dem CORS-Paket und Express wie folgt implementiert werden:

```js
const express = require('express');
const cors = require('cors');

const app = express();

// Einfache CORS-Konfiguration: Erlaubt Zugriffe von allen Ursprüngen
app.use(cors());

app.get('/simple-route', (req, res) => {
    res.json({ msg: 'Simple Request erfolgreich' });
});

app.listen(3000, () => {
    console.log('Server läuft auf Port 3000');
});
```
*Dadurch das wir hier keine Optionen festlegen wird automatisch ein Wildcard gesetzt `Access-Control-Allow-Origin: *` also alle Clienten haben zugriff.*

Unser Beispiel oben erlaubt ja alle externen Anfragen, Simple Requests erlaubt aber auch die Spezifiierung was erlaubt ist:

- HTTP-Methoden: GET, HEAD, POST.
- Nur bestimmte Standard-Header wie `Accept`, `Accept-Language`, `Content-Language`, `Content-Type `(aber nur mit bestimmten Werten wie `application/x-www-form-urlencoded`, `multipart/form-data`, `text/plain`) sind erlaubt.
- Keine zusätzlichen manuellen HTTP-Header.

Hier ist ein Beispiel, wie ein Simple Request mit spezifischem Origin Header in Node.js aussehen könnte:

```js
const express = require('express');
const cors = require('cors');

const app = express();

// CORS für Simple Requests mit spezifischem Origin
app.use(cors({
    origin: 'http://example.com'
}));

app.get('/simple-route', (req, res) => {
    res.json({ msg: 'Simple Request mit spezifischem Origin' });
});

app.listen(3000, () => {
    console.log('Server läuft auf Port 3000');
});
```

### Preflight-Requests

Preflight-Requests sind für komplexere Anfragen vorgesehen, die nicht den Kriterien für Simple Requests entsprechen. Dazu zählen Anfragen, die andere HTTP-Methoden als GET, HEAD oder POST verwenden oder Anfragen, die einen anderen Content-Type als die für Simple Requests zugelassenen haben. Ein Preflight-Request wird mit der HTTP-Methode OPTIONS vor der eigentlichen Anfrage gesendet und enthält Header wie Access-Control-Request-Method und Access-Control-Request-Headers, die dem Server mitteilen, welche Art von Anfrage folgen wird.

Der Server antwortet auf den Preflight-Request mit Headern, die angeben, ob die eigentliche Anfrage zulässig ist. Diese Antwort kann Header wie Access-Control-Allow-Methods und Access-Control-Allow-Headers enthalten, die spezifizieren, welche Methoden und Header in der tatsächlichen Anfrage verwendet werden dürfen.

Wenn die Anfragen über die Kriterien von Simple Requests hinausgehen was folgende Punkte einschließt:

- Verwendung anderer HTTP-Methoden als GET, HEAD, POST.
-Hinzufügen von nicht standardmäßigen HTTP-Headern oder Verwendung von Content-Types außerhalb der für Simple Requests erlaubten.
- Anfragen, die mit Credentials (wie Cookies) gesendet werden.

Hier ist ein Beispiel für eine CORS-Konfiguration, die einen Preflight-Request benötigen würde:

```js
const express = require('express');
const cors = require('cors');

const app = express();

// Detaillierte CORS-Konfiguration für Preflight-Requests
const corsOptions = {
    origin: 'http://example.com', // Spezifischer Ursprung
    methods: 'POST', // Erlaubte Methoden
    allowedHeaders: ['Content-Type', 'Authorization'] // Erlaubte Header
};

// Aktiviert CORS nur für diese spezielle Route mit den definierten Optionen
app.options('/complex-route', cors(corsOptions)); // Preflight-Request
app.post('/complex-route', cors(corsOptions), (req, res) => {
    res.json({ msg: 'Preflight Request erfolgreich bearbeitet' });
});

app.listen(3000, () => {
    console.log('Server läuft auf Port 3000');
});
```

### Preflight-Requests Responses

Die Antwort des Servers auf einen Preflight-Request kann verschiedene Header enthalten, die die Regeln für die folgende eigentliche Anfrage festlegen. Zu diesen Headern gehören Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Expose-Headers, Access-Control-Max-Age, Access-Control-Allow-Methods und Access-Control-Allow-Headers. Diese Header geben an, welche Ursprünge, Methoden und Header für die Cross-Origin-Anfrage erlaubt sind und wie lange die Antwort des Preflight-Requests gültig bleibt.

Durch die Kombination dieser CORS-Methoden können Entwickler:innen in Node.js aber auch jeder anderen Programmiersprache die Kommunikation zwischen verschiedenen Ursprüngen auf eine sichere und kontrollierte Weise handhaben, was die Entwicklung von robusten und interaktiven Webanwendungen ermöglicht.

***Sources:***

[Express CORS Docs](https://expressjs.com/en/resources/middleware/cors.html) 


[Wikipedia](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing)

CORS: Ermöglicht sichere Web-Interaktionen über verschiedene Hosts

retro-cors.png

Cross-Origin Resource Sharing

CORS

security

Von for und while bis zu forEach und map, entdecke die Javascript Schleifen-Typen.

javascript-loops.webp

Javascript und seine Schleifen-Typen

Ein Ritt durch Iterationen

tutorial

howto

Worker Threads stehen seit der Node.js-Version 10.5 als experimentelles Feature zur Verfügung und wurden in der [Version 12.11.0](https://nodejs.org/docs/v12.11.0/api/worker_threads.html) auch als stabil eingestuft. Zum Zeitpunkt dieses Artikels war die Node.js-Version 20.9.0 die aktuelle LTS-Version.

JavaScript ist traditionell eine Singlethreaded-Sprache, was bedeutet, dass alle Operationen nacheinander in einem einzigen Thread ausgeführt werden. Dies hat zur Folge, dass unser Programm warten muss, bis die letzte Aufgabe im Main-Thread abgearbeitet ist, was dazu führen kann, dass unsere Anwendung einfriert. 
Um dieses Problem zu lösen, wird in JavaScript die Aufgabenbearbeitung über den sogenannten Event-Loop gesteuert. Der Event-Loop ermöglicht es, asynchron und nicht-blockierend zu agieren, selbst wenn JavaScript eine Single-Threaded-Sprache ist. I/O-Aufgaben (Netzwerkanfragen, Dateizugriffe und Benutzereingaben), die in der Regel nicht rechenintensiv sind, können somit durch den Event-Loop asynchron abgearbeitet werden.

Wer mehr über den Event-Loop erfahren möchte dem lege ich zwei Videos ans Herz, das eine etwas kürzer das andere etwas länger.

https://www.youtube.com/watch?v=lqLSNG_79lI https://www.youtube.com/watch?v=cCOL7MC4Pl0

Die asynchrone Bearbeitung unserer Aufgaben ist in der Regel der synchronen Verarbeitung und den Worker Threads vorzuziehen. Leider trifft dies nicht auf rechenintensive Aufgaben wie beispielsweise Bildkomprimierung oder komplexe Berechnungen zu. Diese könnten den Main-Thread blockieren und somit unsere Anwendung zum Einfrieren bringen. Genau aus diesem Grund wurden Worker Threads eingeführt.

Worker Threads ermöglichen es uns, Aufgaben auf verschiedene Threads zu verteilen. Dies hat den Vorteil, dass der Main-Thread frei bleibt und unsere Anwendung reibungslos weiterlaufen kann. Die Verteilung der Aufgaben auf mehrere Threads kann zudem zu einem Leistungsgewinn führen.

Jetzt könnte man logischerweise annehmen, einfach alle Aufgaben in Worker Threads auszulagern. An dieser Stelle muss ich jedoch enttäuschen: In der Regel ist das asynchrone Abarbeiten von Aufgaben die effizientere Methode und meistens den Worker Threads vorzuziehen. Dies liegt häufig daran, dass Worker Threads einen hohen Overhead mit sich bringen, da jeder Worker erst gestartet werden muss. Das führt dazu, dass die asynchrone Bearbeitung der Aufgaben in den meisten Fällen auf aktuellen Computern schneller ist. Nur bei wirklich rechenintensiven Aufgaben könnte es sinnvoll sein, auf Worker Threads zurückzugreifen.

Ich möchte anhand der Berechnung von Fibonacci-Zahlen erläutern, wann es sinnvoll ist, auf Worker Threads zu setzen und wann man darauf vielleicht verzichten sollte.

## Exkurs: Fibonacci-Folge

Damit alle wissen was Fibonacci-Zahlen sind und auch um den Code weiter unten besser zuverstehen hier ein versuch das euch etwas näher zubringen. Ihr könnt es aber auch überspringen da ich einfach eine möglichkeit gebraucht habe Komplexe berechnungen durchzuführen. Aber auch ganz unabhängig vom Nutzen von Fibonacci-Zahlen.

### Was ist nun die Fibonacci-Folge?

Die Fibonacci-Folge ist eine Folge von Zahlen, bei der jede Zahl die Summe der beiden vorherigen Zahlen ist. Die Sequenz beginnt typischerweise mit 0 und 1.

```bash
n-0 + n-1 + n-1
n-2 + n-3 + n-5
n-8 + n-13 + n-21
n-34 + n-55 + n-89
n-144 ...
```
Eine kleine kleine Analogie für Dummies ;-)

Stell dir die Fibonacci-Folge als eine Reihe von Boxen vor welche hintereinander aufgereit sind. Jede der Boxen enthält eine Zahl. Die ersten zwei Boxen haben also die Zahl 0 und 1.

Wenn du die Zahl der nächsten Box wissen möchtest addiere die zahlen aus den letzten beiden Boxen:

```bash
Box1: 0
Box2: 1
Box3: 1 // 0 + 1
Box4: 2 // 1 + 1
Box5: 3 // 1 + 2
Box6: 5 // 2 + 3
```
## Vergleich zwischen Main-Thread und Worker-Thread

Ich habe hier eine iterative Fibonacci-Funktion in node.js erstellt, die alle Fibonacci-Zahlen nur einmal berechnet und sie in einem Array speichert. Diese Methode ist sehr effizient und hilft uns gut zu simulieren, wann der Einsatz von Worker Threads aus Performance-Gründen sinnvoll ist und wann eher nicht.

## Ohne Worker Threads

```js
const rounds = 100;

const fibonacci = (n) => {
  const numbers = [0, 1];
  for (let i = 2; i <= n; i++) {
    numbers[i] = numbers[i - 1] + numbers[i - 2];
  }
  return numbers[n];
};

const startWithoutWorker = Date.now();
for (let i = 0; i < rounds; i++) {
  fibonacci(100);
  process.stdout.write(`\r${i + 1}/${rounds}`);
}
const endWithoutWorker = Date.now();
console.log(
  ` Total duration without worker threads (ms): ${
    endWithoutWorker - startWithoutWorker
  }`
);
```
Wir beginnen mit der Berechnung und legen fest, dass diese 100-mal durchgeführt werden soll. Dies wiederholen wir 100-mal damit wir die Auslastung besser simulieren. Das Ergebnis sieht wie folgt aus:

```bash
100/100 Total duration without worker threads (ms): 5
```
100.000-mal:
```bash
100/100 Total duration without worker threads (ms): 127
```
1.000.000-mal:
```bash
100/100 Total duration without worker threads (ms): 1378
```
10.000.000-mal:
```bash
100/100 Total duration without worker threads (ms): 10790
```
All unsere Berechnungen wurden im Event-Loop ausgeführt (Single-Threaded). Zum Vergleich schauen wir uns nun die gleichen Berechnungen mit Worker Threads an.

## Mit Worker Threads

![Javascript Worker Threads {{ w: 1000, h: 300 }}](/uploads/Javascript_Worker_Threads_67c1927e7b.svg) 

Dazu erstellen wir zwei Dateien: eine "worker.js", der wir die Aufgaben zur Berechnung übergeben, und eine Datei, die den Worker aufruft, "index.js". Beginnen wir mit der letzteren. Ich werde hier nicht auf die Funktionsweise und die Implementierung von Worker Threads eingehen; dafür empfehle ich, die [Node.js-Dokumentation](https://nodejs.org/docs/v20.9.0/api/worker_threads.html)!

```js
// index.js
import { Worker } from "worker_threads";

const rounds = 100;
const maxConcurrentWorkers = 16;

let completedRounds = 0;

const startWithWorker = Date.now();

function runWorker() {
  if (completedRounds >= rounds) {
    return;
  }

  const worker = new Worker("./worker.js");
  worker.on("message", (result) => {
    completedRounds++;
    process.stdout.write(`\r${completedRounds}/${rounds}`);
    if (completedRounds === rounds) {
      const endWithWorker = Date.now();
      console.log(
        `\nTotal duration with worker threads (ms): ${
          endWithWorker - startWithWorker
        }`
      );
      process.exit();
    } else {
      runWorker();
    }
  });
  worker.postMessage(100);
}

for (let i = 0; i < maxConcurrentWorkers; i++) {
  runWorker();
}
```
Genau wie in unserem Beispiel ohne Worker Threads führen wir die Berechnung 100-mal durch (const rounds = 100;). Da wir nun aber mit Worker Threads arbeiten, können wir diese Berechnungen auf die Worker auslagern und sie parallel durchführen, was als "Parallelisierung" bezeichnet wird. Hierbei ist zu beachten, dass man bei CPU-intensiven Aufgaben in der Regel einen Worker pro CPU-Thread verwenden möchte. Bei stark I/O-lastigen Aufgaben in einem Worker Thread könnte es jedoch sinnvoll sein, mehr Worker pro CPU-Thread zu nutzen. Da wir eine stark CPU-gebundene Berechnung durchführen, macht es Sinn, nur so viele Worker zu erstellen, wie wir CPU-Threads zur Verfügung haben. In meinem Fall sind das bei meiner CPU (Ryzen 5800X3D) 16 Threads.

Und hier noch der Code für den Worker:

```js
// worker.js
import { parentPort } from "worker_threads";

const fibonacci = (n) => {
  const numbers = [0, 1];
  for (let i = 2; i <= n; i++) {
    numbers[i] = numbers[i - 1] + numbers[i - 2];
  }
  return numbers[n];
};

parentPort.on("message", (n) => {
  const result = fibonacci(n);
  parentPort.postMessage(result);
});
```

Beginnen wir also nun mit unseren Berechnungen, dieses Mal jedoch mit Worker Threads.

100-mal:
```bash
Total duration with worker threads (ms): 605
```
100.000-mal:
```bash
Total duration with worker threads (ms): 730
```
1.000.000-mal:
```bash
Total duration with worker threads (ms): 1222
```
10.000.000-mal:
```bash
Total duration with worker threads (ms): 5237
```
10.000.000-mal (mit nur einem Worker):
```bash
Total duration with worker threads (ms): 14259
```
Was wir jetzt sehen, ist folgendes: Bis zu 1.000.000 Durchläufen ist die Fibonacci-Berechnung im Main-Thread deutlich schneller als die Berechnung mit Worker Threads. Erst bei einer sehr hohen Anzahl an Fibonacci-Berechnungen machen sich die Worker Threads bemerkbar. Und auch das nur, wenn wir genügend Worker bereitstellen. Begrenzen wir dies auf nur einen Worker, dauert die Berechnung sogar deutlich länger. Die Gründe dafür sind vielfältig, der wichtigste ist jedoch der hohe Overhead den Worker Threads mit sich bringen.

Jeder Worker muss zunächst eine V8-Instanz starten, was sowohl Zeit kostet als auch zusätzlichen Speicher belegt. Das bedeutet, das man zusätzlich auch den Speicherbedarf im Auge behalten muss.

## Fazit

Unser kleines Experiment zeigt, dass in den meisten Fällen der Einsatz von Worker Threads nicht empfehlenswert ist, zumindest wenn es darum geht, die Performance der Anwendung zu steigern. Nur für wirklich rechenintensive Aufgaben könnten Worker Threads relevant sein.

Ein weiterer Pluspunkt für Worker Threads könnte bei Aufgaben liegen, die parallel im Hintergrund ablaufen können und nicht auf Benutzereingaben angewiesen sind. Zum Beispiel könnte ein Programm einen Bilderupload anbieten und die Bilder im Hintergrund komprimieren. Dadurch bleibt der Main-Thread und somit der Event-Loop frei, und die Anwendung läuft nicht Gefahr, einzufrieren.

Ich hoffe, ich konnte etwas Licht ins Dunkel von "Worker Threads" bringen. Falls ich Fehler gemacht habe oder etwas unklar ist, lasst es mich gerne in den Kommentaren wissen.


Ich möchte hier zeigen wann es sinn macht Worker Threads einzusetzen und wann ihr es vielleicht lassen solltet

JavaScript-Worker-Threads-Single-Threaded-vs-Mult-Threaded.png

Singlethread- vs. Multithread

Javascript Worker Threads

nodejs

Obwohl es eine ausführliche [Dokumentation](https://domo-2.gitbook.io/brc-20-experiment/) von den Erstellern des BRC20 Token Standards gibt, ist diese in vielen Teilen sehr theoretisch. Das ist grundsätzlich gut, aber wenn man nur alle paar Monate Zeit hat, sich mit dem Thema Ordinals und dessen Ökosystem auseinanderzusetzen und jedes Mal erneut die Dokumentation durchgehen muss, finde ich das eher lästig als hilfreich. Deshalb habe ich mich entschlossen, eine kleine Schritt-für-Schritt-Anleitung zu erstellen, wie man Tokens erstellt, mintet und transferiert.

Dieses Tutorial setzt voraus, dass eine vollständig synchronisierte Bitcoin-Core Wallet und Ord Wallet installiert wurde. Weiterhin gehe ich davon aus, dass jemand, der die Ord Wallet installiert hat, auch weiß, wie er sie bedienen muss. Daher werde ich in diesem Beitrag nicht weiter darauf eingehen. Solltet ihr dennoch Interesse an einer Anleitung dazu haben, lasst es mich in den Kommentaren wissen.

**Vorrausetzungen zusammengefasst:**

- Vollständig synchronisierte Bitcoin-Core Wallet
- [Ord Wallet Installiert](https://github.com/ordinals/ord)
- Einige UTXOs auf der Ord Wallet vorhanden

## 1. Deploy: Wie du deinen eigenen BRC20 Token erstellst

### 1.1 Deploy Textdatei erstellen

Zuerst erstellen wir eine Textdatei. Dabei ist es wichtig, dass der MIME-Typ: "text/plain" und der Zeichensatz "charset=utf-8" ist.

Wie dies funktioniert, variiert je nach Betriebssystem. IDEs und Editoren wie Notepad++ zeigen jedoch in der Regel an, welcher Zeichensatz und welcher MIME-Typ gesetzt ist. In dieser Anleitung erkläre ich den Vorgang für Linux bzw. die Shell. Dies sollte auch unter Windows in einer WSL-Shell funktionieren.

Ich erstelle meine Textdatei mit "iconv" und nenne meinen Token beispielhaft "sil3":

```bash
echo "" | iconv -t UTF-8 > deploy-sil3.txt
```
### 1.2 Token Spezifizieren

Jetzt bestimmen wir, wie unser Token heißen soll und welche Menge davon vorhanden sein wird. Im Grunde spezifizieren wir unseren Token, um ihn später fest und unveränderlich in der Timechain zu verankern.

Bearbeitet nun die Textdatei und fügt den folgenden Inhalt ein. Passt dabei natürlich den Namen "tick", die maximal verfügbare Menge an Token "max" und das Limit "lim" für die maximale Anzahl an Token pro Minting-Vorgang an.

```json
{
  "p": "brc-20",
  "op": "deploy",
  "tick": "sil3",
  "max": "21000000",
  "lim": "1000"
}
```
Hier eine Kurze Erklärung was die Einzellnen Schlüssel bedeuten:

"p": = Protokoll: Hilft anderen Systemen, Brc-20-Ereignisse zu identifizieren und zu verarbeiten
"op": = Operation: Art des Ereignisses (Bereitstellen, Mint, Transfer)
"tick": = Ticker: max. 4-Buchstaben-Kennung des BRC-20
"max": = Max. Versorgung: Stellen Sie die maximale Versorgung des BRC-20 ein
"lim": = Max. Limit pro Mint

### 1.3 Token einschreiben (Inscribe)

Jetzt können wir unseren Token deployen. Dies geschieht mit dem folgenden Befehl und bitte lesst vorab die Erläuterung durch:

```bash
ord wallet inscribe --destination  ZIEL_ADRESSE ~/deploy-sil3.txt --fee-rate 26
```

**Erläuerung:**

--destination:

Dies ist ein optionaler Befehl, den ich euch jedoch empfehlen würde einzusetzen. In unserem Fall gehen wir davon aus, dass wir uns vorab eine Adresse mit dem Befehl `wallet receive generiert haben. Diese Adresse sollten wir immer beim Minten und Transferieren angeben. Der Grund dafür ist, dass die Ord Wallet bei Nichtangabe jede Inscription auf eine neue Adresse schreibt. Das bedeutet, wenn wir z.B. 10 Mal eine Mint-Inscription für unsere Tokens erstellt haben, besitzen wir auch 10 verschiedene Adressen. Möchten wir nun 10.000 Tokens (10 x 1.000) versenden, müssten wir für jede dieser Adressen eine Transfer-Inscription erstellen, da die Tokens der einzelnen Adressen nicht zusammengefasst werden können. Dies ist nur möglich, wenn alle Tokens auf derselben Adresse liegen. So sparen wir letztendlich sowohl Zeit als auch Transaktionsgebühren.

--fee-rate:

> Wichtig: Prüft Vorab auf https://mempool.space/ welche Gebühren aktuell erhoben werden, setzt diese nicht zu niedrig!

![Mempool_TX_Fees {{ w: 590, h: 223 }}](
/uploads/Mempool_TX_Fees_8afcd1a1b2.png?format=webp&quality=100) 

> Notiz: Ihr könnt als Ziel-Adresse natürlich auch jede andere Taproot Adresse angeben. Beachtet aber dabei das nicht alle Wallets wissen wie Sie mit Inscriptions umgehen sollen. Daher nutzt nur Offiziel unterstützte Wallet (Unisat, Xverse, Hiro, Ordinalsafe).

> Optional: Wenn ihr den Befehl vorab testen wollt schreibt einfach ein `--dry-run` hinter `wallet inscribe`.

Nach dem ihr den Befehl abgesendet habt, solltet ihr eine ähnliche Ausgabe erhalten:

```json
{
  "commit": "..",
  "inscription": "...",
  "reveal": "...",
  "fees": 9594
}
```

commit: Ist die TXID welche ihr jetzt mit Mempool verfolgen könnt. Einfach danach suchen.

### 1.4 Prüfen

Ob alles erfolgreich war prüfe ich immer auf OKX da ich finde das dieser den besten Ordinals Explorer bietet. Ihr könnt aber auch jeden anderen nutzen der euch genug Informationen liefert.

Beispiel ORDI Token: [OKX-Explorer](https://www.okx.com/explorer/btc/inscription/brc20/348020) 

## 2. Mint: Token erstellen

Nach dem wir mit "Deploy" unseren Token definiert haben kann nun jetzt jeder User mit dem "Mint" Prozess sich seinen Anteil an Tokens sichern.

### 2.1 Mint Textdatei erstellen

Genau wie beim Deployment erstellen wir uns wieder ein Textdatei.

```bash
echo "" | iconv -t UTF-8 > mint-sil3.txt

```

Der Inhalt schaut nur ein wenig anders aus:

```json
{
  "p": "brc-20",
  "op": "mint",
  "tick": "sil3",
  "amt": "1000"
}
```
Erläuterung:

amt: Gibt den zu prägenden Betrag des BRC-20 an.

> Wichtig: "amt" darf nicht das Limit überschreiten welches wir im Deployment festgelegt haben.

### 2.2 Mint einschreiben (Inscribe)

Der Befehl ist der selbe wie beim Deployment vorgang, wir müssen nur das richtige Textfile angeben. Ich empfehle hier auch wieder immer auf die gleiche Adresse (destination) die Tokens zu Minten.

```bash
ord wallet inscribe --destination  ZIEL_ADRESSE ~/mint-sil3.txt --fee-rate 26
```

Nach dem ihr den Befehl abgesendet habt, solltet ihr eine ähnliche Ausgabe erhalten:

```json
{
  "commit": "..",
  "inscription": "...",
  "reveal": "...",
  "fees": 9594
}
```
Ob alles geklappt hat kann wieder mit dem [OKX-Explorer](https://www.okx.com/explorer/btc/inscription/brc20/348032) überprüft werden.

> Notiz: Natürlich könnt ihr beim Minten auch direkt in eure Unisat oder Xverser Wallet Minten. Dann ist "Punkt 3. Transfer" für euch nicht mehr wichtig.

## 3. Transfer: Tokens versenden

Der Transfer ist etwas umständlich und besteht aus folgenden schritten:

- Einschreiben (Inscribe) "Transfer"
- Senden von "Transfer" Inscription an Zieladresse

### 3.1 Vorbereitung

Wir müssen hier stets eine "--destination" angeben, die ausreichend Token besitzt. Deshalb ist es so wichtig, dass wir beim Minten immer dieselbe Adresse verwenden. Nehmen wir an, dass wir 10-mal 1.000 Tokens auf die gleiche Adresse gemintet haben, können wir nun bis zu 10.000 Tokens direkt transferieren.

Wie beim Deployment und Minten, erstellen wir uns wieder ein Textdatei.

```bash
echo "" | iconv -t UTF-8 > transfer-sil3.txt

```

Dieses Mal fügen wir folgenden Inhalt hinzu und geben bei der zu transferierenden Menge (amt) in unserem Beispiel "5000" Tokens an, die wir versenden möchten:

```json
{
  "p": "brc-20",
  "op": "transfer",
  "tick": "TokenName",
  "amt": "5000"
}
```
### 3.2 Transfer einschreiben

Wie auch schon beim Deployen und Minten ist auch hier die vorgehensweise die selbe. Wir geben bei unserem Befehl die --destination an welche genug Tokens hält (min. soviele wie wir versenden möchten) und achten darauf das wir die eben erstellte transfer-sil3.txt Datei angeben.

```bash
ord wallet inscribe --destination  ZIEL_ADRESSE ~/transfer-sil3.txt --fee-rate 26
```
Nach dem ihr den Befehl abgesendet habt, solltet ihr eine ähnliche Ausgabe erhalten:

```json
{
  "commit": "..",
  "inscription": "...",
  "reveal": "...",
  "fees": 9594
}
```
### 3.3 Prüfen

Sobald die Transaktion bestätigt wurde könnt ihr wieder in eurem [Explorer](https://www.okx.com/explorer/btc/inscription/brc20/348126) eurer Wahl prüfen ob der Token Transfer gültig ist. 

## 4. Versenden von Tokens an eine andere Adresse

Dieser vorgang ist jetzt relativ simpel. Ihr sendet einfach die eben erstellte "Transfer" Inscription an eine andere Ordinals fähige Adresse.

Dies geht mit folgenden Befehl:

```bash
ord wallet send --fee-rate 26 DESTINATION ADRESSE INSCRIPTION_ID
```

**Erläuterung:**

Destination Adresse: Wohin ihr die Tokens verschiecken wollt
INSCRIPTION_ID: Die Inscription ID von der eben erstellten "Transfer" Inscription.

## Fazit

Der Umgang mit dem BRC20-Token kann anfangs überwältigend erscheinen. Trotz umfassender Dokumentationen fehlt es oft an praxisnahen Anleitungen. Deshalb habe ich dieses Tutorial erstellt, um die Token-Erstellung, -Prägung und -Transferierung verständlich darzustellen. Besonders hervorzuheben ist die Bedeutung von einheitlichen Adressen beim Minten. Dies spart nicht nur Zeit, sondern auch Transaktionsgebühren. Mit dieser Anleitung hoffe ich, Einsteigern einen klaren und einfachen Weg im Umgang mit dem BRC20-Token und der Ord Wallet aufzuzeigen.






Praxisnaher Leitfaden zum Erstellen, Prägen und Transferieren von BRC20-Tokens.

React Hooks: Der useState Hook

Basics-Trilogie

02.07.2025

React Hooks: Der useEffect Hook

Basics-Trilogie

01.07.2025

Intersection Observer API

Elemente überwachen - ganz ohne Blockierung des Hauptthreads

26.05.2025

Next.js Server Actions & Tanstack Query

Das Dream-Team für dein Datenmanagement?

06.04.2025

Wie du ein Paket auf JSR.io veröffentlichts

mit Deno 2

13.10.2024

Metallic-Flakes Material in three.js und next.js

Wir wir einen Metallic Flakes Material erstellen

11.09.2024

React Hooks: Der useRef Hook

Basics-Trilogie

23.05.2024

Next.js Server Actions

Super Simple

14.04.2024

CORS

Cross-Origin Resource Sharing

22.02.2024

Ein Ritt durch Iterationen

Javascript und seine Schleifen-Typen

31.10.2023

Javascript Worker Threads

Singlethread- vs. Multithread

28.10.2023

Deploy, Mint und Transfer mit der Ord Wallet

Alles was du wissen musst

23.09.2023