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

metropolis.png

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

SSH-Keys-Config-ed25519.png

Invalid-Regular-Expression-Image.png

oh-my-zsh-mid.png

Ice cream gingerbread danish muffin cheesecake icing tiramisu.

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

CODING LIFE AND EVERYTHING & MEISTENS AUF DEUTSCH

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

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