null vs. undefined

null bedeutet: es gibt einen Wert, und er ist absichtlich leer.

undefined bedeutet: dieser Wert wurde nie gesetzt. Oder: das Konzept existiert hier nicht.

Das klingt nach Haarspalterei. Es ist aber einer der häufigsten Orte, an dem Business-Semantik unbemerkt in eine Lücke fällt.

Das Problem

Wenn eine API null zurückgibt für „kein Nutzer” und der Frontend-Code mit undefined prüft, ergibt sich ein stiller Fehler. Kein Exception. Nur falsches Verhalten.

Schlimmer: Wenn Teams nicht konsequent entscheiden, ob ein fehlendes Datum null, undefined oder gar nicht vorhanden ist, akkumuliert sich stiller Zustand, der nur unter bestimmten Bedingungen explodiert.

Die Regel (vereinfacht)

• null: explizite Leerstelle. Ein Wert war gemeint, existiert aber gerade nicht.
• undefined: kein Wert vorgesehen. Nicht initialisiert, nicht gesetzt, nicht bekannt.

Haltet das konsistent im gesamten Stack. Von API über Domain bis zur Komponente.

TypeScript hilft — wenn man es lässt

strictNullChecks erzwingt, dass null und undefined unterschiedlich behandelt werden müssen. Wer das deaktiviert, gibt die Kontrolle ab.

type User = {
  name: string;
  deletedAt: Date | null; // explizit leer (gelöscht)
  lastLogin?: Date; // optional — könnte gar nicht existieren
};

Der Unterschied ist im Typsystem. Er sollte auch in den Köpfen verankert sein.