Start · Sprachen · JavaScript · Referenz · TaskSignal.priority

TaskSignal.priority

Eigenschaft

Schreibgeschützte Eigenschaft, die die aktuelle Priorität eines <code>TaskSignal</code> liefert: <code>"user-blocking"</code>, <code>"user-visible"</code> oder <code>"background"</code>.

seit JavaScript Prioritized Task Scheduling API – Chrome/Edge 94+, Kategorie: webapi

Signatur

get TaskSignal.priority

Beschreibung

Die Eigenschaft priority gehört zur Schnittstelle TaskSignal aus der Prioritized Task Scheduling API. Sie gibt an, mit welcher Priorität Aufgaben ausgeführt werden, die über scheduler.postTask() mit diesem Signal eingeplant wurden. Mögliche Werte sind "user-blocking" (höchste Priorität, z. B. für die direkte Reaktion auf Eingaben), "user-visible" (Standard) und "background" (niedrigste Priorität, z. B. für Protokollierung oder Vorabladen).

Die Eigenschaft selbst ist nur lesbar. Ändern lässt sich die Priorität nur über den zugehörigen TaskController mit controller.setPriority(neuePriorität). Danach meldet das Signal den neuen Wert und löst das Ereignis prioritychange aus. Alle Aufgaben, die noch warten und dieses Signal nutzen, werden dann mit der neuen Priorität neu eingereiht.

In der Praxis nutzt man priority, um die aktuelle Priorität zu protokollieren oder zu prüfen. Außerdem kann man innerhalb eines prioritychange-Handlers auf die neue Priorität reagieren, etwa indem man Folgeaufgaben passend einplant oder den Status in der Oberfläche anzeigt.

Rückgabewert

Typ
"user-blocking" | "user-visible" | "background"
Beschreibung
Ein String mit der aktuellen Priorität des Signals. Wird beim TaskController keine Priorität angegeben, ist der Wert "user-visible".

Beispiele

Priorität eines neuen Signals auslesen

// Controller mit Hintergrund-Priorität anlegen
const controller = new TaskController({ priority: 'background' });
console.log(controller.signal.priority);

// Ohne Angabe gilt der Standardwert
const standard = new TaskController();
console.log(standard.signal.priority);
background user-visible

Priorität zur Laufzeit ändern und auf prioritychange reagieren

const controller = new TaskController({ priority: 'background' });
const { signal } = controller;

signal.addEventListener('prioritychange', (event) => {
  console.log(`Priorität geändert: ${event.previousPriority} → ${signal.priority}`);
});

scheduler.postTask(() => console.log('Aufgabe läuft mit', signal.priority), { signal });

// Der Nutzer wartet jetzt auf das Ergebnis, also Priorität erhöhen
controller.setPriority('user-blocking');
Priorität geändert: background → user-blocking Aufgabe läuft mit user-blocking

Mit Feature-Erkennung sicher verwenden

const runTask = async (fn, priority = 'user-visible') => {
  if (!('scheduler' in globalThis) || !('TaskController' in globalThis)) {
    // Ersatz für Browser ohne Unterstützung
    return new Promise((resolve) => setTimeout(() => resolve(fn()), 0));
  }
  const controller = new TaskController({ priority });
  console.log('Eingeplant mit Priorität:', controller.signal.priority);
  return scheduler.postTask(fn, { signal: controller.signal });
};

const ergebnis = await runTask(() => 21 * 2, 'background');
console.log(ergebnis);
Eingeplant mit Priorität: background 42

// Wichtig · Fallstricke

  • Nur lesbar: Eine Zuweisung wie signal.priority = 'background' hat keine Wirkung und wirft im Strict Mode einen TypeError. Zum Ändern immer TaskController.prototype.setPriority() verwenden.
  • Die Priorität steht nur bei Signalen aus einem TaskController zur Verfügung. Ein normales AbortSignal aus einem AbortController hat keine priority-Eigenschaft.
  • Wird bei postTask() zusätzlich die Option priority angegeben, gilt diese als feste Priorität. Das Signal dient dann nur noch zum Abbrechen, und spätere Änderungen an signal.priority betreffen diese Aufgabe nicht.
  • Ruft man setPriority() innerhalb eines prioritychange-Handlers für dasselbe Signal auf, wird ein NotAllowedError geworfen.
  • Kompatibilität: Unterstützt in Chromium-Browsern ab Version 94 und in neueren Firefox-Versionen, nicht in Safari. Deshalb immer per Feature-Erkennung prüfen oder ein Polyfill einsetzen, z. B. scheduler-polyfill.