Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

Node.js für ASP.NET-Entwickler

Die CommonJS-Module-Spezifikation

Testen Sie unsere 2015 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Durch die "CommonJS Module Specification" kann man auf andere JavaScript-Dateien zugreifen. Das Modulsystem wurde entwickelt, um die Möglichkeit zu bieten, bereits existierenden Code wiederzuverwenden.

Transkript

In diesem Video beschäftigen wir uns mit einem ganz wichtigen Thema unter Node.js, und zwar mit den Modulsystemen. Wie schaut hier eben das Dependency Management aus, und zwar gibt es unter Node.js eben die CommonJS Module Specification. Und die ist wichtig, denn mit dieser kann man eben auf andere JavaScript-Dateien zugreifen, wo eben Funktionalität schön in eigene Dateien ausgelagert werden kann. Und woher kommt denn überhaupt diese CommonJS Module Specification? Erst mal die CommonJS, kurz CJS, ist eben eine Initiative, die es sich zum Ziel gesetzt hat, eben Spezifikationen für JavaScript zu definieren, um JavaScript besser weiterentwickeln zu können für die modernere Entwicklung. Und daraus ist eben dann diese Module Spezifikation entstanden, und ja man sagt auch heute nochmal CommonJS dazu. Und damit ist es eben dann möglich, existierenden Code wieder zu verwenden, und daher wurde eben das Modulsystem entwickelt. Es ist sehr stark eben dann vergleichbar mit Assemblies und Namespaces, was wir aus .NET kennen. Auch da lagern wir ja eigene Logiken aus in eigene DLL-Dateien, in eigene Assemblies. Das wollen wir natürlich unter JavaScript ebenfalls, aber halt eben dann in eigene JavaScript-Dateien. Das Schöne aber auch an CommonJS ist, dass es eine wirklich einfache Syntax ist, um auf andere Dateien zuzugreifen. Und das ist halt eben dafür entworfen worden, also hauptsächlich dann für die Backend-Entwicklung, also für Node.js, weil man möchte nämlich synchron die JavaScript-Dateien laden. Das bedeutet, wenn wir in einer Webanwendung auf JavaScript-Dateien zugreifen wollen, haben wir einen sogenannten Script-Tag, wo wir dann im Source-Attribut die JavaScript-Datei referenzieren. Und das haben wir serverseitig nicht. Wir haben ja nur Plain-JavaScript. Ursprünglich ist es eben wirklich fürs synchrone Laden entworfen worden. In der aktuellen Version ist auch das asynchron möglich, was aber nicht unbedingt zwingend notwendig wäre. Das Ganze kann auch, zum Beispiel, kompilieren, so wie man das dann ungefähr aus CoffeeScript, zum Beispiel, kennt. Und wo wird überhaupt CommonJS auch überall verwendet? Zum Beispiel unter Node.js, CouchDB und Titanium Mobile, da wird diese Spezifikation also sehr stark verwendet. Für einen Browser ist es also weniger geeignet. Da hat sich dann, zum Beispiel, ab ECMAScript 6 das Asynchronus Module Definition System durchgesetzt, also AMD. Und es gibt auch noch viele weitere Frameworks wie RequireJS oder viele weitere, die das eben auch mitanbieten, und das ist etwas, was wieder nicht so schön ist in der JavaScript-Welt, dass man dann wieder auf dem Client etwas Anderes macht wie auf dem Server. Und dem kann man zum Glück dank TypeScript abhelfen, weil das ist möglich mit TypeScript hier, das Ganze später automatisiert, je nachdem, wo später der JavaScript-Code ausgeführt wird, den Code entsprechend aufbereiten zu lassen. Aber das sehen wir in einem späteren Video. Das Wichtige hinter diesem ganzen Modulsystem ist, dass wir uns vorstellen müssen, CommonJS ist eben eine statische Instanz, die hinter Node.js läuft. Und jedes Modul, was wir jetzt auf der Grafik sehen, einmal Modul A und Modul B, ist für sich so, wie wir hier gekapselt sehen auch wirklich in einem eigenen Kontext. Das ist sehr angenehm, weil es gibt natürlich ein ganz großes Problem unter JavaScript im Browser, zum Beispiel, auch. Worauf man achten muss, ist, dass nichts im Global Scope liegt, das heißt, jede Variable, die man erzeugt, die kann man aus jeder JavaScript-Datei fast wieder aufrufen. Und der Nachteil ist, wenn man irgendein Framework nutzt, dass dann eben derselbe Variablenname verwendet wird, dass alles überschrieben, ohne dass wir das merken. Das ist halt so das große Globalproblem, was hier automatisch bei Node.js nicht mehr der Fall ist. Das heißt, jedes Modul ist für sich eigenständig gekapselt. Das ist wirklich wichtig, zu wissen. Das heißt, eben auf Objekte, Funktionen und Variablen von anderen Modulen kann nicht zugegriffen werden, außer wenn wir dann eben mittels "require()" auf dieses Modul zugreifen. Dann kann das Ganze geladen werden. Das ist sehr stark eben vergleichbar mit einem "using", was wir aus .NET kennen. Und erstellt man jetzt hier ebenso eine Variabel wie "foo", kann man halt eben alles, was innerhalb von diesem Modul ist und was man halt auch explizit mit öffentlich stellt, was also dann nicht private ist, kann man dann über diese Variable zugreifen. Wie wir jetzt hier recht sehen, habe ich eine "foo"-Variable, und wir können jetzt auf die Funktion "bar" zugreifen, weil diese öffentlich gestellt wurde. Das Wichtige ist, das Modul muss nicht zwingend eine Datei sein und kann theoretisch auch irgendwo aus einer Datenbank kommen. In der Praxis ist es aber eine Datei. Und man kann zusätzlich oben, sehen wir jetzt den Namen "foo", das bedeutet ./, damit eben "require" automatisch nachsieht im Route-Verzeichnis, ob es eine "foo.js"-Datei gibt. Man muss aber diese Dateiendung nicht zusätzlich mitangeben. Handelt sich das bei dem Modul um ein Node Package Modul, was installiert wurde, dann muss man den Strich, also den Punkt und den Strich nicht mitangeben. Und dann schaut eben Node.js automatisch dort nach. Ist es nicht der Fall, macht man eben diesen Punkt und den Slash dazu, .js muss man nicht dazu schreiben. Wie bereits erwähnt, asynchron kann man auch auf die Daten zugreifen. Es wird aber in den wenigsten Fällen wirklich gebraucht. Auch ein Requiring Over HTTP ist möglich, das heißt, wir könnten auch Module direkt über HTTP laden. Ich selber habe dieses Feature auch nicht gebraucht, aber es ist einfach interessant, dass das natürlich geht. Wie kann man dann innerhalb von dem Modul etwas öffentlich stellen? Das heißt, innerhalb von seiner JavaScript-Datei greift man auf "module.exports" zu, und dann gibt man dementsprechend den Variablennamen mit. Hier wäre es in dem Fall "Say, Hello". Und wenn man "Say, Hello" jetzt von außen irgendwo aufruft, wird automatisch diese anonyme Funktion mit "console.log" ausgeführt. Ganz wichtig, Module sind auch statisch, das heißt, man kann an unterschiedlichen Stellen dann ein "require" von dem Modul auslösen. Und man bekommt immer exakt dieselbe statische Instanz zurückgeliefert, und das ist natürlich auch total praktisch. Es gibt dann auch noch Globale Variablen. Obwohl wir, wie schon gesagt, normalerweise nicht mehr so global sind, gibt es dennoch unter Node.js globale Variablen, und die Beliebtesten und Wichtigsten wären hier, zum Beispiel, auch "_filename" oder "_dirname". Und durch die Unterstriche wird das auch nochmal klar ersichtlich. Und dazu möchte ich einmal kurz mal Node.js öffnen. Dazu wechsle ich nochmal zu der Eingabeaufforderung, schreibe dann nochmal "node". Und wenn ich jetzt "global" tippe, sehen wir eben, was wirklich alles im Global Scope liegt, und das ist sehr, sehr interessant, das heißt, wir sehen natürlich hier JavaScript API-Funktionen, wie "setTimeout", "setInterval". Also das ist alles, was hier global uns hier eben zur Verfügung gestellt wird. Dann gibt es hier auch Pfade, die hiermit durchgereicht werden. Ich greife mir etwas höher zu, dann sehen wir hier auch schon mal die ersten Unterstriche. Und das ist auch nochmal extrem spannend, und zwar gibt es dann die "env"-Variablen, wo wir halt wirklich nochmal darauf zugreifen können, was für ein Betriebssystem läuft, den hier gerade auf dieser Node-Instanz, wo ist das Windows-Verzeichnis. Also man kann hier extrem viele Informationen nochmal abfragen. Hier sieht man nochmal, welche Module geladen wurden. Und das war eigentlich schon alles, was wir für den kurzen Einstieg von Modulen wissen müssen.

Node.js für ASP.NET-Entwickler

Sehen Sie, wie Sie den Umstieg auf auf native JavaScript-Entiwcklung mit Node.js erfolgreich meistern.

2 Std. 52 min (31 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Exklusiv für Abo-Kunden
Erscheinungsdatum:15.05.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!