ES6 Modules - Traceur - Abwärtskompatibilität
0 
molily
ES6 Modules - Traceur - Abwärtskompatibilität
Meine Herren!
Ich hantiere derzeit etwas mit der kommenden Version von Javascript und traceur (ein Compiler, der die Vorab-Version in gegenwärtiges Javascript übersetzt).
Insbesondere habe ich mich just mit nativen Modulen befasst.
Beim Schreiben diverser, minimalistischer Test-Apps bin ich auf folgendes Problem gestoßen:
Ich habe die Bibliothek d3 im Einsatz, korollar ist d3 eine Abhängigkeit meiner App. Bisher binde ich diese Bibliothek stets über ein eigenes script-Element ein. Alle anderen Abhängigkeiten kann ich ohne Umwege programmatisch auflösen. Mir missfällt es, dass ich derzeit also zwei verschiedene Wege gehen muss, um meine Modul-Abhängigkeiten zu bewältigen.
Illustriert an einem Beispiel:
<!DOCTYPE html>
<html>
<head><title>Demo</title></head>
<body>
<script src="d3.js"></script>
<script type="module">
module $ from DOM;
// … Code, der auf $ und d3 angewiesen ist.
</script>
</body>
</html>
Ich hätte es dagegen lieber einheitlich, beispielsweise so:
<!DOCTYPE html>
<html>
<head><title>Demo</title></head>
<body>
<script type="module">
module $ from 'DOM';
module d3 from 'd3';
// … Code, der auf $ und d3 angewiesen ist.
</script>
</body>
</html>
Das klappt nicht, vermutlich weil d3 selbst nicht in ES.next geschrieben ist und deshalb auch keine Schnittstelle exportiert. Ich weiß von d3 aber, dass es als CommonJS-Module vertrieben wird. Ansonsten bietet d3 auch die traditionelle Möglichkeit der Einbindung, einen Namensraum im globalen Objekt zu erzeugen.
Die Spezifikation liest sich recht holprig, da fehlt mir noch Erfahrung. Deshalb delegiere ich die Frage mal an meine Herren (und Damen, für den Fall der Fälle). Also die konkrete Frage: Gibt es eine native Möglichkeit die gegenwärtige Version von d3 (geschrieben in ES5 und ohne module-Definition) in meinem ES.next-Modul auf standardkonforme Art einzubinden? Anders formuliert, gibt es eine elegante Möglichkeit in ES.next Module zu benutzen, die nicht nach ES.next Modul-Spezifikation verfasst worden sind? Es ist eine Frage der Abwärtskompatibilität.
Entschuldigt die abstrakte Schreibe, ich wüsste leider nicht, wie ich ohne Einbußen an Präzision, besser formulieren könnte. Fragt einfach, wenn ich etwas im Unklaren gelassen habe.
PS: Wat war dat für eine Zangenjebucht.
rheinische Grüße
- dat Raoul
--
“All right, then, I'll go to hell.” – Huck Finn
“All right, then, I'll go to hell.” – Huck Finn
-
Hallo,
gibt es eine elegante Möglichkeit in ES.next Module zu benutzen, die nicht nach ES.next Modul-Spezifikation verfasst worden sind?
Mit entsprechenden Loadern bestimmt, aber Traceur kann das anscheinend nicht.
Aber du kannst D3 das d3-Objekt exportieren lassen. Dazu müsstest du dessen Code anpassen.
var d3 = { version: "3.4.3" }; export default d3; // Der Rest…Die IIFE muss dann auch weg.
Mathias
-
Meine Herren!
gibt es eine elegante Möglichkeit in ES.next Module zu benutzen, die nicht nach ES.next Modul-Spezifikation verfasst worden sind?
Mit entsprechenden Loadern bestimmt, aber Traceur kann das anscheinend nicht.
Aber du kannst D3 das d3-Objekt exportieren lassen. Dazu müsstest du dessen Code anpassen.
var d3 = {
version: "3.4.3"
};
export default d3;
// Der Rest…> > Die IIFE muss dann auch weg. Ernüchternd :/ d3 selbst möchte ich nur ungern modifizieren und einen Module-Loader möchte ich wegen der zusätzlichen Komplexität auch eher vermeiden, obwohl das sicher die weitsichtigste Möglichkeit wäre. Für den Moment belasse ich es dann bei der klassischen Variante. Danke für deine Hilfe. -- “All right, then, I'll go to hell.” – Huck Finn -
Meine Herren!
gibt es eine elegante Möglichkeit in ES.next Module zu benutzen, die nicht nach ES.next Modul-Spezifikation verfasst worden sind?
Mit entsprechenden Loadern bestimmt, aber Traceur kann das anscheinend nicht.
Aaaah, hat was gebraucht bis mir dieses Licht aufgegangen ist. Ich habe zu verbissen an require.js als Loader gedacht, und habe darüber hinaus nicht weiter nachgeforscht. Aber ES6 bietet selbst eine programmatische API für Loader an. Mit dieser API wird es dann möglich sich so in den Lade-Prozess eines Moduls einzuklinken, dass man gloable Definitionen als Modul-Exporte neuinterpretiert.
Jedem, der sich mit ES6-Modulen beschäftigt, kann ich dieses gist wärmstens ans Herz legen, eine sehr aufschlussreiche Anwendungsfall-Diskussion.
--
“All right, then, I'll go to hell.” – Huck Finn
-