Startseite / Artikel / Verständnis von JavaScript Proxies: Fallen, Reflect und reaktive Muster

JavaScriptProxyReflectReactive ProgrammingWeb Development

Verständnis von JavaScript Proxies: Fallen, Reflect und reaktive Muster

Erfahren Sie, wie die Proxy- und Reflect-Objekte in JavaScript den Zugriff auf Eigenschaften abfangen, um Validierungen, virtuelle Eigenschaften sowie reaktive Frameworks zu ermöglichen.

1096 Wörter

Jedes Mal, wenn Sie obj.property schreiben oder mit obj.property = value einen Wert zuweisen, nutzen Sie Operationen, die von JavaScript stillschweigend ausgeführt werden, wobei es keine eingebauten Möglichkeiten gibt, zu beobachten oder zu ändern, was im Hintergrund geschieht. Das Proxy-Objekt beseitigt diese Annahme völlig. Es ermöglicht es Ihnen, ein Zielobjekt zu umhüllen und diese grundlegenden Operationen – Lesen, Schreiben, Löschen – bereits vor deren Ausführung abzufangen. Dieses Abfangmechanismus ist tatsächlich der eigentliche Antrieb hinter vielem, was in modernen JavaScript-Bibliotheken und -Tools wie „Magie“ erscheint.

Ein Wrapper, der alles abfangen kann

Ein Proxy befindet sich zwischen Ihrem Code und dem Objekt, das er umhüllt, und eine Sammlung von Fangfunktionen entscheidet darüber, was tatsächlich bei jeder Art von auf das Objekt ausgeführter Operation geschieht.

const config = { retries: 3, timeout: 5000 };

const guardedConfig = new Proxy(config, {
  set(target, key, value) {
    if (key === "retries" && (typeof value !== "number" || value < 0)) {
      throw new TypeError("retries must be a non-negative number");
    }
    target[key] = value;
    return true;
  },
});

guardedConfig.retries = 5;   // works fine
guardedConfig.retries = -1;  // throws TypeError, caught before it ever reaches the object

Die Schreibweise guardedConfig.retries = 5 unterscheidet sich in keiner Weise von einer gewöhnlichen Eigenschaftszuweisung. Genau das ist der Zweck der Konzeption: Die Abfangung bleibt am Aufrufort unsichtbar. Man kann Validierungen, Protokollierung oder andere Nebeneffekte auf das scheinbar einfache Zugriffsmuster auf Eigenschaften aufbauen, ohne Änderungen am Code vornehmen zu müssen, der das Objekt tatsächlich verwendet.

Der Mechanismus hinter reaktiven Frameworks

function reactive(target, onChange) {
  return new Proxy(target, {
    get(obj, key) {
      return obj[key];
    },
    set(obj, key, value) {
      const changed = obj[key] !== value;
      obj[key] = value;
      if (changed) onChange(key, value);
      return true;
    },
  });
}

const state = reactive({ count: 0 }, (key, value) => {
  console.log(`${key} changed to ${value}, re-rendering...`);
});

state.count = 1; // "count changed to 1, re-rendering..." — no explicit call needed

Die Schreibweise state.count = 1 liest sich wie eine völlig normale Zuweisung, denn syntaktisch ist sie tatsächlich eine. Was ihr Bedeutung verleiht, ist die set-Falle, die diese unscheinbare Zeile in ein Ereignis verwandelt, auf das der Rest des Systems reagieren kann. Das ist die eigentliche Grundlage, auf der reaktive Frameworks beruhen. Es gibt keinen speziellen „beobachtbaren“ Datentyp, den man überall aktivieren müsste. Es handelt sich dabei um einfache Objekte, die in einen Proxy eingehüllt sind und jede darauf vorgenommene Schreiboperation stillschweigend erkennen.

Virtuelle Eigenschaften: Werte, die nur dann existieren, wenn man danach fragt

Eine get-Falle kann freiwillig etwas zurückgeben, das tatsächlich nie im zugrunde liegenden Ziel gespeichert wurde – dadurch können berechnete oder abgeleitete Werte so dargestellt werden, als wären es gewöhnliche Eigenschaften.

const product = { name: "Desk Lamp", priceCents: 3499 };

const productView = new Proxy(product, {
  get(target, key) {
    if (key === "priceDollars") {
      return (target.priceCents / 100).toFixed(2);
    }
    return target[key];
  },
});

console.log(productView.priceDollars); // "34.99" — computed on read, not stored anywhere

Es gibt kein priceDollars-Feld irgendwo im product. Es wird dynamisch erzeugt, jedes Mal, wenn darauf zugegriffen wird, innerhalb der get-Falle. Das unterscheidet sich erheblich von einem Getter, den man mit get innerhalb einer Klasse oder eines Objektliterals schreibt, denn eine Proxy-Falle kann den Zugriff auf Schlüssel abfangen, die überhaupt nicht im Voraus deklariert wurden. Das ist nützlich, wenn man beispielsweise eine API-Antwort mit zusätzlichen berechneten Feldern umhüllen möchte, ohne den ursprünglichen Inhalt zu verändern.

Warum Reflect oft zusammen mit Proxy verwendet wird

Es gibt eine Feinheit, die Menschen beim ersten Schreiben einer Falle, die auf ein Standardverhalten zurückgreifen muss, in Verwirrung bringt. Auf naive Weise zu vorgehen führt leicht zu subtilen Fehlern.

const handler = {
  get(target, key) {
    console.log(`reading ${key}`);
    return target[key]; // works, but loses some edge-case correctness
  },
};

Für einfache, reine Objekte funktioniert dieser Ansatz meist gut, doch die sicherere und korrektere Methode, eine Operation auf ihr Standardverhalten umzuleiten, ist Reflect. Es stellt für jede Falle eine Funktion bereit, die die Operation exakt widerspiegelt, dabei die richtige this-Bindung beibehält und auch schwierigere Situationen wie vererbte Getter korrekt handhabt.

const handler = {
  get(target, key, receiver) {
    console.log(`reading ${key}`);
    return Reflect.get(target, key, receiver);
  },
};

Die Aufrufung von Reflect.get(target, key, receiver) erzeugt genau das gleiche Ergebnis wie ein normaler Zugriff auf Eigenschaften, einschließlich Randfällen mit Prototypen und Gettern, die von this abhängen – Situationen also, in denen target[key] stillschweigend ein falsches Ergebnis liefern kann. In praktischem Proxy-Code ist es fast immer üblich, die entsprechende Reflect-Methode von innen aus jeder Trap-Funktion aufzurufen, es sei denn, man möchte das Standardverhalten absichtlich ändern – schließlich garantiert diese Version eine Übereinstimmung mit dem, was ein normaler Eigenschaftszugriff normalerweise tun würde.

Traps, die einschränken anstatt zu erweitern

Traps sind nicht nur nützlich, um Verhalten hinzuzufügen, sie können es genauso leicht wieder entfernen. Ein has-Trap bestimmt, was der in-Operator zurückgibt, und ein deleteProperty-Trap kann die Löschung gänzlich verweigern.

const secureRecord = new Proxy(
  { id: 1, ssn: "123-45-6789" },
  {
    get(target, key) {
      if (key === "ssn") throw new Error("Direct access to ssn is not allowed");
      return Reflect.get(target, key);
    },
    deleteProperty() {
      throw new Error("Deleting fields is not allowed on this record");
    },
  }
);

console.log(secureRecord.id); // 1
console.log(secureRecord.ssn); // throws
delete secureRecord.id; // throws

Diese Art der Schutzmaßnahme unterscheidet sich in wichtiger Hinsicht von einem privaten Klassenfeld: Sie kann auf jedes beliebige Objekt angewendet werden, ohne dass dieses Objekt ursprünglich als Klasse definiert wurde, und sie ermöglicht es, enge, key-spezifische Regeln zu definieren, die eine einfache #private-Markierung nicht ausdrücken kann.

Eine Idee, viele Traps

Jede Falle beantwortet eigentlich dieselbe Frage: Was soll geschehen, sobald Code versucht, diese alltägliche Operation an diesem Objekt auszuführen? Ein Wert lesen, einen schreiben, einen löschen, überprüfen, ob eine Schlüsselwerte existiert – das sind alles normalerweise unsichtbare, automatische Aktionen, und Proxy sorgt dafür, dass jede davon zu einem Moment wird, den man beobachten oder umleiten kann. Reaktive Zustandsysteme, Validierungsverpacker, Zugriffskontrollschichten, virtuelle berechnete Felder – keines dieser Konzepte sind unzusammenhängende Tricks aus verschiedenen Quellen. Sie basieren alle auf dem identischen zugrundeliegenden Mechanismus, werden lediglich auf eine andere Falle ausgerichtet.

Weiterführende Literatur

Alle ArtikelBrief senden