HTML5 Drag & Drop, Teil III: der indirekte Drop-Nachweis

Dieser Artikel ist Teil einer Serie:

  1. Teil 1: Dateien
  2. Teil 2: Elemente
  3. Teil 3: Drop Effect

Der Begriff „Planet“ geht auf das griechische Wort πλανήτης zurück, das ganz grob übersetzt „Umherschweifender“ bedeutet. Das Wort hat sich durchgesetzt, weil schon die alten Griechen die Planeten beobachten konnten und erkannten, dass diese sich am Himmel bewegen, im Gegensatz zu ganz normalen Sternen. Nur der Planet Neptun ist in der Antike nie entdeckt worden, weil er einfach viel zu weit entfernt ist, um ohne weiteres als bewegtes Objekt erkannt zu werden. Einem findigen Mathematiker namen Urbain Le Verrier fiel allerdings 1846 auf, dass die Umlaufbahn des bis dahin als äußerstem Planeten bekannten Uranus ein wenig seltsam war. Uranus verhielt sich so, als gäbe es jenseits seiner Bahn noch eine weitere beträchtliche Gravitationsquelle – sowas wie einen großen Planeten. Le Verrier rechnete aus, wo dieser mysteriöse Extra-Planet zu einer bestimmten Uhrzeit zu sehen sein müsste, setzte jemanden vor ein auf die fragliche Stelle gerichtetes Teleskop und siehe da– der Planet Neptun ward entdeckt. Und wenn wir die Drag & Drop-API von HTML5 komplett bändigen wollen, müssen wir genau wie Monsieur Le Verrier einen indirekten Nachweis führen, nur eben über Geschehnisse im Browser und nicht über astronomische Objekte.

Sinn und Zweck des Drop Effect

Eine Drag & Drop-Operation kann vieles bedeuten. Wenn Element A auf Element B gezogen wird, könnte das eine Kopier- oder auch eine Verschiebe-Operation sein. Man kennt das vom Datei-Manager seines Betriebssystems – je nachdem welche Taste man gedrückt hält, wird eine Datei verschoben oder kopiert oder macht ganz etwas anderes. Die HTML5-API erlaubt es, die mit einer Operation verbundenen Intention (kopieren, verschieben etc.) durch verschiedene Event-Stufen zu transportieren, ähnlich wie Daten transportiert werden. Und ähnlich wie die Daten lässt sich diese Intention bei einigen der Events im Rahmen einer Drag-Operation auslesen – natürlich nicht bei allen Events und auch nicht bei den gleichen Events wie die Daten, aber es geht. Gemäß der Spezifikationen lässt sich die Intention bei den Events dragenter und dragover sowie ggf. bei drop und dragend auslesen, wobei sie jeweils im Event-Objekt in der Eigenschaft dropEffect zu finden ist.

Der dropEffect kann die Werte none, copy, move und link haben, die für jeweils eine Intention stehen. Wie das funktioniert kann man am besten einer einer simplen Demo mit gezogenem Text sehen. Nicht vergessen: die Drag & Drop-API von HTML5 ist die gleiche Funktionalität, die im Browser auch die ganz normalen Drag-Operationen abwickelt. Demnach müsste man in dieser Fiddle unterschiedliche Werte gemeldet bekommen, je nachdem wie man Text auf das Ziel-Div zieht. Drückt man während der Operation die jeweilige Modifikator-Taste (variiert je nach OS; meist ist es ctrl oder alt), so erhält man copy, andernfalls move – immer vorausgesetzt, der Browser verhält sich diebezüglich standardkonform, was Mitte 2014 einzig beim Firefox der Fall ist.

Diese kleine Demo ist kein sinnvolles Beispiel für die Nutzung des Drop Effect, zeigt aber den Gedanken hinter dieser Eigenschaft. Wenn wir den erst mal verstanden haben, können wir den Drop Effect für unsere eigenen Zwecke in unseren eigenen Drag-Operationen nutzen, denn wir können ihn auch selbst setzen … oder besser gesagt beeinflussen.

Den Drop Effect beeinflussen

Bei einer selbstgebauten Drag & Drop-Operation wie unserem Endprodukt aus Teil 2 der Artikelserie können wir im dragstart-Event uns selbst den Drop Effect für unsere Operation aussuchen. Das Problem ist, dass das nicht ganz so einfach ist, wie man vielleicht spontan hoffen mag. Das, was später der Drop Effect wird, wird über eine Eigenschaft namens effectAllowed festgelegt, die nicht die gleichen Werte wie der spätere dropEffect hat. Stattdessen akzeptiert er die Werte none, copy, copyLink, copyMove, link, linkMove, move, all und uninitialized. Jeder dieser Werte resultiert in einem oder mehreren bestimmten Drop Effects, die dieser Tabelle zu entnehmen sind:

effectAllowed mögliche dropEffects
copy copy
move move
link link
copyLink copy, link
copyMove copy, move
linkMove link, move
all copy, link, move

Es gibt noch ein paar weitere effectAllowed-nach-dropEffect-Mutier-Pfade, die jedoch für unseren Use Case von gezogenen Elementen erst mal nicht relevant sind. Man erkennt aber an der Tabelle ein System. Jene effectAllowed-Werte, die auch ein gültiger dropEffect-wären, resultieren in eben genau diesem Wert als dropEffect. Die Kombinationswerte wie copyMove lassen als dropEffect sowohl copy als auch move zu – es kommt dann darauf an, wie genau der Nutzer das Element gezogen hat (d.h. welche Tasten während der Operation gedrückt wurden).

An dieser Stelle können wir an die (z.Z. nur im Firefox funktionierende) Text-Drag-Demo von vorhin andocken, dann das Ganze funktioniert genau so mit Elementen! Man setze beim Start der Drag-Operation einen effectAllowed, der zwei verschiedene dropEffect-Werte zulässt …

$('li').on('dragstart', function(evt){
  evt.originalEvent.dataTransfer.setData('text', '');
  evt.originalEvent.dataTransfer.effectAllowed = 'copyMove';
});

… und schon wird uns je nachdem wie wir das Element ziehen (normal oder mit gedrückter ctrl/alt-Taste) im drop-Event mal der eine, mal der andere dropEffect gemeldet:

$('.dropzone').on('drop', function(evt){
  evt.preventDefault();
  $(this).removeClass('valid');
  window.alert(evt.originalEvent.dataTransfer.dropEffect);
});

Im Firefox ausprobieren! Blöderweise machen es die anderen Browser weniger gut; Chrome und Safari liefern beide beim drop-Event immer none, ganz egal wie der Nutzer das Element durch die Gegend zieht. IE macht es zumindest mit gezogenen Textauswahlen richtig. Je nachdem was wir nun mit dem dropEffect anzustellen gedenken, kann uns das stören oder auch nicht.

Den Drop Effect verwenden

Der dropEffect ist selbst in den Browsern, die ihn nur mittelprächtig implementieren nützlich, doch fokussieren wir uns zunächst auf einen dem Standard entsprechenden Use Case. Dieser wird dann in Firefox, Chrome und Safari funktionieren. Man kann mit kleinen Einschränkungen auch andere Browser unterstützen, aber wir fangen erst mal mit dem vollen Programm an.

Wir können in das Endprodukt aus Teil 2 der Artikelserie recht einfach einen dropEffect einbauen, indem wir bei dragstart den effectAllowed festlegen und und beim drop den dropEffect auslesen. Das wäre für sich genommen erst mal ziemlich nutzlos. Allerdings könnten wir ja tatsächlich die beiden denkbaren effectAllowed-Werte das machen lassen, was sie versprechen – nämlich die gezogenen Elemente kopieren oder verschieben! Der erste Schritt ist das schon erwähnte Einbauen des effectAllowed in dragstart:

$('li').on('dragstart', function(evt){
  var type = $(this).attr('data-type');
  var data = $(this).text();
  evt.originalEvent.dataTransfer.setData(type, data);
  // Kopieren und verschieben zulassen
  evt.originalEvent.dataTransfer.effectAllowed = 'copyMove';
});

Beim drop-Event könnte man nun den dropEffect auslesen und das gezogene Element entweder klonen und in das Ziel-Element einhängen (dropEffect ist copy) oder einfach das gezogene Element direkt adoptieren (dropEffect ist copy). Das ist allerdings aus einer Reihe von Gründen nicht empfehlenswert – nicht zuletzt, weil wir in der Demo <li>-Elemente ziehen und diese keine direkten Kinder von <div>-Elementen sein dürfen. Besser ist es, das gezogene Element anhand der im dataTransfer-Objekt übertragenen Daten nachzubauen:

$('.dropzone').on('drop', function(evt){
  evt.preventDefault();
  $(this).removeClass('valid');
  var key = $(evt.target).attr('data-accept');
  var val = evt.originalEvent.dataTransfer.getData(key);
  // Das gezogene Element als Div "nachbauen"
  $('<div>').text(val).appendTo(evt.target);
});

Der Code deckt nun den copy-Fall ab, jedes gezogene Element wird geklont. Für den move-Fall können wir das dragend-Event nutzen, das auf dem gezogenen Element feuert. Hier fragen wir ab, ob der dropEffect den Wert move hat und entfernen in diesem Fall einfach das gezogene Element:

$('li').on('dragend', function(evt){
  if(evt.originalEvent.dataTransfer.dropEffect === 'move'){
    // Im Fall von Verschiebe-Operation das gezogene Element löschen
    $(evt.target).remove();
  }
});

Fertig! Je nach gedrückter Modifikator-Taste werden die ziehbaren Elemente nun in ihr Ziel-Element kopiert oder verschoben – und das immerhin in Chrome, Firefox und Safari. Und es kommt noch besser: das Script funktioniert jetzt über Browserfenster-Grenzen hinweg! Man kann zwei Firefox-Fenster mit der Fiddle geöffnet haben und von einem Fenster ins andere Elemente ziehen um sie zu kopieren und zu verschieben.

Das Ganze funktioniert aus drei Gründen: zum einen ist die API einfach so gebaut, dass sie ganz allgemei Drag & Drop-Operationen verarbeitet. Wo diese Operationen starten, ob im gleichen Browserfenster, in einem anderen Fenster oder ob es sich um eine vom Desktop gezogene Datei handelt, ist der API egal. Zweitens stören uns die Bugs in Chrome und Safari, die im drop-Event den falschen dropEffect melden nicht, da wir ihn nur im dragend-Event abfragen, wo er korrekt ausgegeben wird. Und drittens anderen ist der Code so geschrieben, dass jedes Event nur mit den Daten arbeitet, die die API ihm bereitstellt. Würden wir z.B. das gezogene Element im drop-Event nicht nachbauen, sondern das wirklich gezogene Element adopieren, so könnte das nicht funktionieren – wir bekommen schließlich in Fenster A keinen Zugriff auf Elemente in Fenster B. Nur die Daten der Drag-Operation werden übermittelt, wobei diese dann auch reichen, um einigermaßen überzeugend ein Verschieben über Fenstergrenzen hinweg zu simulieren.

Der große Haken an unserem bisherigen Werk ist, dass es aktuell nur in den modernsten Varianten von Firefox, Chrome und Safari funktioniert. Das lässt sich auch nicht ohne weiteres ändern, allerdings können wir mit einer kleinen Einschränkung des Funktionsumfangs weitere Browser bedienen.

Der eingeschränkte Drop Effect als indirekter Drop-Nachweis

Browser wie der Internet Explorer liefern, egal welche Tasten man drückt, den falschen dropEffect. Aber immerhin: sie liefern einen, vorausgesetzt es hat ein drop-Event stattgefunden. Damit kann man zwar nicht mehr zwischen Kopier- und Verschiebe-Operationen unterscheiden, aber immer noch Elemente von Browserfenster A nach Fenster B ziehen. So wird der dropEffect zu einem einfachen Signal degradiert, mit dem wir in einem Fenster festellen können, was im anderen passiert ist, so wie Urbain Le Verrier die abweichende Bahn von Uranus das Signal für die Existenz von Neptun war.

Der dropEffect ist laut Standard none wenn das drop-Event nicht stattgefunden hat (weil z.B. die dragover-Handbremse nicht gelöst wurde). Wenn das drop-Event stattgefunden hat, ist der dropEffect einer der Werte aus dem effectAllowed-Setting – im Ideallfall der Wert, der der durch Tastendruck untermauerten Intention entspricht. Der IE macht nur den letzten Teil falsch, d.h. browserfensterübergreifende Operationen klappen noch immer! Es gibt nur keine Unterscheidung zwischen verschiedenen Daten (da ja der IE als Daten-Key ausschließlich text zulässt) und Intentionen. Ein entsprechend vereinfachter Fall funktioniert also auch im Internet Explorer!

Fazit

Drag & Drop ist sowohl in nativen Programmen als auch in Webapps ein alter Hut. Die Möglichkeiten im Browser waren aber stets beschränkt. Datenaustausch zwischen Browserfenstern oder einfach nur mehreren Teilen einer App (z.B. iFrames) war kaum möglich. Auch das Ausdrücken von Intention per Tastendruck war bestenfalls knifflig, da ja jedes Betriebssystem-Interface hier seine eigenen Regeln aufstellt. Um hier auf das native Level zu kommen brauchte es zwingend eine Browser-API.

Mit HTML5 wird das Web in Sachen Drag & Drop-Fähigkeiten zumindest in die richtige Richtung geschoben. Theoretisch, d.h. auf dem Spezifikations-Papier, ist alles da, was man braucht und die mißratene API ließe sich mit einer kleinen Abstraktionsschicht in den Griff kriegen. Mir ist noch keine entsprechende Library bekannt, allerdings würde der flächendeckende Einsatz auch mit Astraktionsschicht am Intenet Explorer scheitern, der selbst in der neuesten Version gleich mehrere Features nicht unterstützt. Sollte sich das demnächst ändern, sind auch im IE mit Webapps komplizierte Dateisortier-Interfaces oder Multi-Fenster-Apps möglich … vorausgesetzt ein findiger JavaScript-Nerd bringt die API mal in benuztzbare Form.

Fragen zu HTML5 und Co beantwortet 13 - Headlines, Main-Ersatz, DOM-Überwachung, Parent-Selektoren

Leser fragen und der Erklärbär antwortet nun schon zum dreizehnten Male, heute zu den Themen HTML5-Semantik, DOM und CSS-Selektoren. Falls ihr hierzu oder zu anderen Browser-Themen noch mehr Fragen auf Lager habt, dann schreibt mir eine E-Mail oder gebt die Frage per Twitter ab.

Was passt in Headline-Elemente?

Ist es in HTML5 erlaubt, <p>-Elemente in den Headline-Elementen <h1> bis <h6> zu benutzen?

Nein, in Überschriften dürfen laut Spezifikationen nur Elemente aus der Kategorie phrasing content vorkommen. Das in etwa die Elemente, die man früher unter inline elements subsummiert hätte und so sind <p>-Elemente nicht mit von der Partie. Tipps für kompliziertere Überschrift-Strukturen hat dieser Artikel auf Lager. Am sinnvollsten ist es vermutlich, Überschrift und Absatz in einem gemeinsamen <header>-Element überzubringen.

Laut offizieller Empfehlung für komplexere Überschriften sollte man einfach ein Überschriften-Element zusammen mit z.B. <p>-Elementen in ein gemeinsames <header>-Element verfachten. Möglichweise wird es auch eines Tages ein Element der Marke <subhead> geben; erste Überlegungen hierzu existieren, aber definitiv ist hier noch gar nichts.

Herausfinden welches Element in welchem Element vorkommen darf ist im Übrigen ein Kinderspiel: einfach in den Spezifikationen das Element heraussuchen (hier die Headline-Elemente) und in der grünen (beim W3C blauen) Infobox die Punkte Content model und Contexts in which this element can be used ansehen; der erste verrät, was in diesem Element vorkommen darf, der zweite in welchen anderen Elementen dieses Element stehen kann.

Was ist der beste Ersatz für <main>?

Wenn ich <main> nicht benutzen kann, weil ich alte Browser unterstützen muss, wäre dann ein <section role="main"> oder ein <div role="main"> der richtigere Ersatz?

Ich halte es für etwas schwierig, hier das eine für falscher oder für richtiger zu erklären. Grundsätzlich gilt, dass man immer das passende Element verwenden sollte und nichts anderes. Die Spezifikationen sagen ganz eindeutig: Authors must not use elements, attributes, or attribute values for purposes other than their appropriate intended semantic purpose. So gesehen wären <div role="main"> und <section role="main"> beide nicht richtig, denn es gibt ja <main>. Daher mein Tipp: alten Browsern mittels html5shiv das neue Element einfach beibringen!

Wenn wir uns dann dazu entschließen (aus welchen Gründen auch immer) es falsch zu machen, sehe ich auch keinen so großen Unterschied zwischen <div> und <section> ausmachen. Für das <div> spricht, dass es genau wie <main> keinen Eintrag in der Outline erzeugt, so dass das vermutlich die bessere Wahl wäre. Aber man muss auch ganz ehrlich sagen, dass wir uns, wenn wir mit der Outline argumentieren, schon ganz weit draußen in der Theoriewüste bewegen. Für alles was relevant ist (SEO, Lesbarkeit des Quelltexts, Barrierefreiheit) ist es wirklich ziemlich egal, solange das role-Attribut da ist.

Es gilt wie immer die Faustregel für semantisches HTML: wenn man die Wahl zwischen A und B hat und nach 5 Minuten Nachdenken und Recherche nicht zweifelsfrei klar ist, was richtiger ist, ist es vermutlich ziemlich egal.

DOM-Änderungs-Events

Wie bekommt man mit, wenn sich ein Element im DOM ändert, es zum Beispiel sichtbar gemacht wird?

Für dieses Problem gibt es mehrere Lösungsansätze – die einen funktionieren in vielen Browsern und sind eher schlecht, die anderen sind eher gut, funktionieren bloß fast nirgends. Die beste Lösung ist der Mutation Observer (Specs, MDN), der einen Überwachungsprozess für einen DOM-Knoten darstellt. Mit new MutationObserver(callback) wird ein solcher Überwachungsprozess erstellt und mit der Methode observe(target, options) auf ein Ziel-Element angesetzt:

var target = document.querySelector('p');

// Neue MutationObserver-Instanz
// Das Callback-Argument "changes" ist ein Array von Änderungen,
// self ist der MutationObserver selbst
var observer = new MutationObserver(function(changes, self){
  console.log('Änderung registriert', changes);
  self.disconnect(); // Überwachung beenden
});

// Startet die Überwachung von "target" mit den im Objekt
// gelisteten Optionen. Hier interessieren wir uns nur für
// Änderungen des Class-Attributs
observer.observe(target, {
  attributes: true,
  attributeFilter: ['class']
});

MutationObserver können Inhalt, Attribute und Subtree eines Elements überwachen. Was genau überwacht werden soll, wird im zweiten Parameter der observe()-Methode angegeben. Wenn Änderungen passieren, feuert der beim erstellen des Observers angelegte Callback, wo die einzelnen Änderungen dem Array im ersten Parameter zu entnehmen sind. Hier ist das Ganze in Aktion

Was Mutation Observer nicht können, ist überall funktionieren – im IE gibt es sie z.B. erst ab Version 11 (siehe Can I use). Allerdings gibt es in vielen Browsern noch Fragmente der Mutation Events (MDN), die auf anderem Wege auch das Ziel der DOM-Überwachung im Visier hatten. Aus unter anderem Gründen der Performanceoptimierung (Observer sind viel schneller) wurden die Mutation Events allerdings relativ schnell offiziell aufgegeben, sind aber immerhin bis runter zum IE 9 noch vorhanden. Was tun, wenn man zwei verschiedene APIs hat die das Gleiche machen? Man nutzt einen Polyfill, der alle Browser und APIs vereinheitlicht, sofern sie denn überhaupt eine Möglichkeit zur DOM-Überwachung bieten. In IE 8 oder noch älteren Semestern ist DOM-Überwachung also nicht möglich, in allen anderen kriegt man das Problem zumindest auf eine einheitliche API zurechtgebogen.

Rückwärts matchende CSS-Selektoren?

Gibt es eine Möglichkeit per CSS alle Geschwisterelemente eines Elements anzusprechen? Mit dem General Sibling Combinator bekomme ich nur die nachfolgenden Geschwisterelemente, aber nicht die vorhergehenden.

Aktuell gibt es keine Möglichkeit, in CSS irgendwie rückwärts zu matchen, d.h. Elternelemente oder vorhergehende Geschwisterelemente anzusprechen. In Selectors Level 4 wird z.Z. ein für Parent-Selektoren benutzbares Feature beschrieben (E! > F spricht E an, wenn es das Elternelement von F ist), aber dieses Feature gibt es aktuell in keinem Browser und es ist auch alles andere sicher, dass sich das je ändern wird.

Das Grundproblem ist, dass CSS-Selektoren eigentlich eine Einbahnstraße sind. Browser lesen aus Performancegründen Selektoren wie .foo + section a immer von rechts nach links. In der Regel gibt es pro zu stylendem Element mehr CSS-Regeln nebst Selektoren, die das Element nicht betreffen als solche, die relevant sind. Um möglichst zügig entscheiden zu können, welche Styles der Browser auf ein Element anwenden muss, arbeitet er nach einem von rechts nach links laufendem Ausschlussverfahren.

Im Falle von .foo + section a beginnt er mit allen <a>-Elementen (was schon mal 95% aller übrigen Kandidaten aus der Suche eliminiert) und sortiert dann alle aus, die kein <section>-Element als Vorfahren haben. Am Ende fliegen dann <a>-Elemente, deren <section>-Vorfahren nicht direkt auf Elemente mit der Klasse foo vor sich haben aus der Auswahl und es bleiben nur die durch den Selektor beschriebenen Elemente übrig. Auf diese Weise wird der Löwenanteil der Element-Kandidaten im ersten Schritt (ist das Ziel-Element ein <a>?) aussortiert und der Rest-Selektor braucht gar nicht ausgewertet zu werden. Von links ausgewertete Selektoren würden es erfordern, dass große Teile des DOM gründlich nach möglichen Kandidaten durchsucht werden, also z.B. auch <section>-Elemente, die gar keine <a>-Elemente enthalten.

Bei einem Selektor für alle Geschwisterelemente ist das Performance-Problem vielleicht nicht ganz so groß, aber trotzdem müsste man der CSS-Engine beibringen, auch folgende Elemente in das Ausschlussverfahren mit einzubeziehen. Und das ist ein Feature, das es aktuell einfach aufgrund der fundamentalen Konzeption des Selektor-Parsers (Stichwort Bottom-Up-Parser) nicht gibt.

Dinge wie ein Parent-, oder Geschwister-Selektor würden den Matching-Algorithmus also um einiges komplizierter und vor allem langsamer machen. Der durch die Einführung eines Parent-Selektors entstehende Geschwindigekeitsnachteil wäre so groß, dass die Spezifikationen von Selectors Level 4 sogar unterschiedliche Performance-Profile definieren, von denen eins besonders schnell ist, aber eben Features wie den Parent-Selektor nicht unterstützt.

Müsste ich wetten, würde ich nicht darauf setzen, dass der Parent-Selektor oder ein Geschwisterelemente-Kombinator zeitnah in unseren Browsern aufschlägt.

Weitere Fragen?

Auch eure Fragen zu HTML5, JavaScript und anderen Webtechnologien beantworte ich gerne! Einfach eine E-Mail schreiben oder Twitter bemühen und ein bisschen Geduld mit der Antwort haben. Ansonsten kann man mich natürlich auch als Erklärbär zu sich kommen lassen.

ECMAScript 6: Rest, Spread und Defaults

Wenn ich Programmierern, die bisher mit Webentwicklung eher wenig am Hut hatten, JavaScript nahebringe, fange ich gerne mit den Bad Parts, den WTFs und den Wats an. Dann haben wir den unangenehmen Teil schnell hinter uns, ein paar Vorurteile werden bestätigt und Witze kann man damit auch schön reißen. Dass JS auch ein paar sehr feine Eigenschaften hat, kommt dann nach und nach von selbst zum Vorschein. Allerdings schickt sich ECMAScript 6 an, dieses Vorgehen in Zukunft zu erschweren, denn dort steht natürlich die Beseitigung (oder zumindest Abschwächung) der Bad Parts ganz oben auf der Agenda und eine dieser Maßnahmen zur WTF-Reduzierung sind Features rund um Funktionsparameter  da ist der Aufräumbedarf nämlich besonders hoch.

Fehlende Features und das Arguments-Problem

In JavaScript ist in Sachen „Bedienkomfort und Funktionsparameter“ viel Luft nach oben. So sieht in ECMAScript 5 der einzige Weg, Vorgabewerte für Funktionsparameter zu definieren, so aus:

var fn = function(x){
  if(typeof x === 'undefined'){
    x = 42;
  }
}

Das funktioniert einigermaßen, ist aber alles andere als komfortabel. Das nächste Problem zeigt sich, wenn man mit einer nach oben offenen Anzahl an Parametern zu arbeiten versucht. Innerhalb von Funktionen findet sich in JavaScript immer eine Variable namens arguments, die eine Liste der die Funktion beim Aufruf übergebenen Werte enthält und eigentlich mehr nach einem Feature als nach einem Problem aussieht:

var fn = function(){
  console.log(arguments);
};
fn('Hallo', 42)

// In der Konsole erscheint: ["Hallo", 42]

Die Sache hat aber einen Haken: arguments ist kein Array, sondern nur ein array-ähnliches Objekt. Spürbar wird der Unterschied vor allem darin, dass array-ähnlichen Objekten all die nützlichen Methoden fehlen, die Arrays so bieten: slice(), map(), forEach() und so weiter. Möchte man diese nutzen, so muss man arguments in ein echtes Array verwandeln, indem man es mit Array.prototype.slice() bearbeitet:

var fn = function(){
  var args = [].slice.call(arguments);
  return Array.isArray(args); // > true
};

Das ist zwar nur ein Einzeiler und für den geübten JavaScript-Entwickler nichts besonderes, aber trotzdem ist es schon recht lästig, dass man diese Umwandlung manuell vornehmen muss. Möchte man einen Schritt weiter gehen und nur einen Teil der Funktionsargumente als Array erhalten und den Rest weiterhin als normale Parameter verwenden, wird es endgültig unbequem:

var fn = function(a, b){
  var rest = (arguments.length >= 3) ? [].slice.call(arguments, 2) : [];
  console.log(rest);
};

fn(23, 42);             // > []
fn(23, 42, 1337, 9001); // > [1337, 9001]

Umgekehrt ist ist es auch nicht viel besser: hat man ein Array von Parametern für eine Funktion, so kommt man nicht um Function.prototype.apply() herum. Während das für sich genommen noch halbwegs unschlimm ist (abgesehen von der erforderlichen manuellen this-Festlegung), kann man, wenn man apply() benutzt, zusätzliche Werte ausschließlich durch Umbau des Arrays in die Funktion geben:

function fn(){
  console.log(arguments);
}

// Diese Args haben wir...
var args = [23, 42, 1337, 9001];

// ... aber vorher muss noch das hier dazu
args.unshift(2.718, 3.141);

fn.apply(undefined, args);
// > [2.718, 3.141, 23, 42, 1337, 9001] 

Eine Syntax für den Use Case „Funktionsaufruf mit A, B und allem was in diesem Array ist“ gibt es nicht, obwohl das ja nun wirklich keine abwegige Idee ist.

Die gute Nachricht ist, dass ECMAScript 6 all diese Probleme in Angriff nimmt. Es gibt eine Syntax für Funktionsparameter-Vorgabewerte und die neuen Rest- und Spread-Operatoren schicken arguments und Array-Gebastel in Rente. Wohlgemerkt: nur in Rente! Denn komplett abschaffen lassen sich die Bad Parts nicht …

Rest statt Arguments

Oberflächlich betrachtet wäre es ein schöner Fortschritt, wenn ECMAScript 6 arguments reparieren und in ein richtiges Array verwandeln würde. Das ist allerdings nicht möglich, da es da draußen im Web viel Code gibt, der fest davon ausgeht, dass arguments eben kein Array ist – und niemand möchte, dass plötzlich Scripts auf Webseiten nach einen Browserupdate einfach nicht mehr funktionieren. Also braucht es eine andere, arguments ergänzende Lösung, die in ES6 in Form von Rest-Parametern (ECMAScript-Wiki, MDN) daherkommt.

Rest-Parameter sind spezielle letzte Parameter in einer Funktionsdefinition, die mehrere an die Funktion übergebene Werte einfangen und in einem echten Array zur Verfügung stellen. Sie werden in der Funktionsdefinition mit drei vorangestellten Punkten markiert, tragen aber innerhalb der Funktion einen ganz normalen Variablennamen:

// Funktion mit zwei normalen Parametern
// Alle weiteren Parameter landen im Array "rest"
function fn(a, b, ...rest){
  return rest;
}

var rest = fn(23, 42, 1337, 9001); // > [1337, 9001]
Array.isArray(rest);               // > true

Für an CoffeeScript gewohnte Entwickler ist anzumerken, dass es nach aktuellem Stand nicht möglich sein wird, Rest-Parameter für etwas anderes als die letzten Parameter einer Funktion zu verwenden, so wie hier:

# Klappt, nur in CoffeeScript, nicht in ES6
fn = (x, rest..., y) -> rest
fn(23, 42, 1337, 9001) # > [42, 1337]

Die Vorteile von ...rest gegenüber arguments liegen auf der Hand: es ist ein echtes Array mit eingebauten Slice für die jeweils letzten an eine Funktion übergebenen Daten. Das arguments-Objekt wird aus Gründen der Abwärtskompatibilität bis ans Ende aller Tage ein Bestandteil von JavaScript bleiben, aber benutzen wird man es wesentlich seltener. Auch für Fälle, in denen man alle Funktionsparameter in einer Liste haben möchte, ...rest dank der vielen nützlichen Array-Methode vorzuziehen:

function add(...args){
  return args.reduce(function(a, b){
    return a + b;
  }, 0);
}

add(23, 42, 1337, 9001); // > 10402

Das heißt also im Endeffekt: arguments wird von ECMAScript 6 in den wohlverdienten Ruhestand geschickt.

Spread als Apply-Ergänzung

Möglicherweise ebenfalls aus CoffeeScript bekannt sind Spreads (ECMAScript-Wiki, MDN) mit denen sich eine Funktion mit einem Array von Parametern aufrufen lässt:

function sum(...args){
  return args.reduce(function(prev, curr){
    return prev + curr;
  }, 0);
}

var zahlen = [23, 42, 1337, 9001];
var summe = sum(...zahlen); // > 10402

Spreads vereinfachen nicht nur hier und da den Code, sondern ermöglichen auch Dinge, die mit ECMAScript 5 schichtweg nicht nur mit ausgesprochen mühsamen Tricks machbar waren. In ES5 gibt es Function.prototype.apply(), was verwendet werden kann um eine Funktion mit einer Liste von Werten als Arguments aufzurufen:

var summe = add.apply(null, [23, 42, 1337, 9001]);

Der Haken an apply() ist, dass man zwingend ein Objekt angeben muss, dass von der aufgerufenen Funktion als this verwendet werden soll. Das ist aber nicht immer möglich, z.B. bei Constructorfunktionen. Diese zeichnen sich ja gerade dadurch aus, dass sie ihr this-Objekt selbst erstellen und können daher nur mit new, nicht aber unter Zuhilfenahme apply() aufgerufen werden können. So weigert sich beispielsweise der Date-Constructor ohne new ein Objekt zu produzieren und spuckt stattdessen einen String aus:

var dateParams = [ 2014, 6 ];
new Date(dateParams[0], dateParams[1])); // > Objekt
Date.apply(null, dateParams));           // > String

Dabei ist Date noch ein relativ harmloses Beispiel – andere Funktionen würden mit apply() überhaupt nicht funktionieren und nicht mal ein falsches Ergebnis liefern. Mit Spreads löst sich der ganze Problemkomplex in Wohlgefallen auf, da es keinen Grund gibt, sie nicht mit Constructorfunktionen zu kombinieren:

var dateParams = [ 2014, 6 ];
new Date(dateParams[0], dateParams[1]); // > Objekt
new Date(...dateParams);                // > Objekt

Außer bei Funktionsaufrufen lassen sich Spreads auch für das Zusammenfügen von Arrays verwenden und ergänzen an dieser Stelle Array.prototype.concat():

var zahlen1 = [23, 42];
var zahlen2 = [1337, 9001, ...zahlen1]; // > [1337, 9001, 23, 42]

Es spricht auch nichts dagegen, die Spread-Syntax mehrfach in einem Funktionsaufruf oder einer Array-Erstellung zu verwenden:

var foo = [42, 1337];
var numbers = [23, ...foo, ...[9001]]; // > [23, 42, 1337, 9001]
sum(...[3.141], ...numbers);           // > 10406.141

Spreads sind einfach eine schöne kleine Ergänzung zur JavaScript-Syntax, die an vielen Stellen das vergleichsweise komplizierte apply() oder andere Hacks überflüssig macht.

Vorgabewerte für Parameter

Ein Feature, das fast jede Programmiersprache schon lange hat, landet mit ECMAScript 6 endlich auch in JavaScript:

function add(a, b = 42){
  return a + b;
}

add(23, 1337); // > 1360
add(23);       // > 65

Die Vorgabewerte werden erst zugewiesen, wenn die Funktion aufgerufen wird, was z.B. Funktionsaufrufe an der Stelle von Werten erlaubt. Im folgenden Beispiel wird für jeden add()-Aufruf auch getDefault() neu aufgerufen, was in unterschiedlichen Ausgabewerten resultiert:

function getDefault(){
  return (Math.random() > 0.5) ? 42 : 23;
};

function add(a, b = getDefault()){
  return a + b;
}

add(23); // > Manchmal 46, manchmal 65

Ein Vorgabewert wird immer dann von der Funktion benutzt, wenn der tatsächlich übergebene Wert undefined ist. Das hat zur Folge, dass man einen Vorgabewert auch durch ein explizites undefined nicht überschreiben kann:

function add(a, b = 42){
  return a + b;
}

add(23, undefined); // > 65

Es zeigt sich: die neue Syntax ist nichts weiter als ein 1:1-Ersatz des althergebrachten manuellen Wenn- Undefined-dann-X-Tests für Parameter, aber einfach wesentlich schöner und bequemer. Und das Beste ist: obwohl noch kaum ein Browser Vorgabewerte für Parameter unterstützt, kann man sie, wie auch Rest und Spread, bereits heute flächendeckend einsetzen.

Unterstützung und Ausblick

Der Firefox ist aktuell der alleinige Champion im Bereich Rest, Spread und Defaults. Rest- und Default-Parameter funktionieren seit Version 15, seit Nummer 15 auch Spreads für Arrays und seit 27 für Funktionen. Beim Rest der Browserwelt sieht es noch finster aus, wie uns die allmächtige Kompatibilitätstabelle wissen lässt. Allerdings werden alle drei neuen Features vom Traceur-Compiler perfekt unterstützt, so dass man sie im Prinzip ab sofort zum Einsatzbringen kann, vorausgesetzt der zusätzliche Kompilierschritt ist nicht zu abschreckend.

Erklärbär-Termine für April und Mai 2014

Druckbetankung mit den neuesten Infos zu HTML5, CSS3, JavaScript und moderner Frontendentwicklung gefällig? Damit kann ich in den nächsten Wochen gleich mehrfach dienen:

  • 7. - 9. April in München: HTML5-Schulung bei der Open Source School. Mein bewährtes drei­tä­gi­ges HTML5-Standardprogramm stattet die Teilnehmer im Druckbetankungsverfahren mit so gut wie allem aus, was man zu HTML5 wissen muss. Von semantischem Markup bis hin zu Canvas-Frameworks ist alles dabei. Geboten wird ein großer Praxisanteil, kleine Arbeitsgruppen und ein Buch gibt es obendrein.
  • 10. und 11. April in München: CSS3 bei der Open Source School. Mein zweitä­gi­ges CSS3-Standardprogramm katapultiert die Teilnehmer in das CSS3-Zeitalter, in dem Webfonts und Farbverläufe fließen. Auch hier steht einen großer Praxisanteil mit überschaubaren Arbeitsgruppen auf dem Plan und mindestens ein CSS3-E-Book gibt es als Bonus.
  • 28. - 30. April in Düsseldorf: HTML5 MasterClass mit Jens Grochtdreis. Dreitägiges Intensivtraining zu HTML5, CSS3 und modernem JavaScript vom HTML5-Erklärbär und dem CSS-Buddha! Schritt für Schritt werden die neusten Webstandards vorgestellt, bis am Ende die Teilnehmer eine eigene kleine HTML5-App entwickeln. Early-Bird-Tickets noch bis zum 28. März!
  • 15. und 16. Mai in München: Online Print Symposium. Am Tutorial-Tag gibt es einen kleinen HTML5-Workshop, später dann einen kleinen, nichttechnischen Vortrag über das Hype-Thema HTML5.

Termine unpassend, Orte alle zu weit weg und Programme nicht genehm? Ich komme auch gerne mit einem maßgeschneiderten Programm vorbei – mich kann man mieten!

Folgt mir!

Kauft mein Zeug!

Cover der HTML5-DVD
Infos auf html5-dvd.de, kaufen bei Amazon

Cover des HTML5-Buchs
Infos auf html5-buch.de, kaufen bei Amazon

Cover des CSS3-Buchs
Infos auf css3-buch.de, kaufen bei Amazon