Varför CommonJS och AMD/RequireJS

Inledning

Till skillnad från webbservrar som Apache och Microsoft IIS, som båda är förkonfigurerade, är node.js helt annorlunda. Med node.js bygger utvecklare webbservrar från grunden. En utvecklares kodningsfärdigheter förväntas skydda webbservern. Därmed skiljer sig Node.js från Apache och resten.

I den här artikeln kommer vi att fokusera på två huvudsakliga systemmoduler – AMD och Common.js – i node.js. Innan vi jämför dem måste vi diskutera skillnaderna mellan de två systemmodulerna. Två vägledande frågor som hjälper oss att jämföra de två är: vilken av dem är snabbare när moduler laddas i eller från webbläsaren och hur man konverterar en systemmodul så att den ärver vissa funktioner från en annan systemmodul.

Denna artikel kommer inte att fokusera på grunderna i node.js amd javascript. Den kommer inte att behandla ämnen som ”hur man installerar node.js”, ”hur man använder npm eller nave för att installera paket” eller ”olika versioner av node.js för olika projekt”. Vårt syfte är att lösa förvirringen mellan AMD och Common.js. Därför kommer vi att betona lätt på kärnmoduler i node.js, ett par funktioner och variabler, och så småningom rikta vår uppmärksamhet mot AMD och Common.js och hur vi kan konvertera en av systemmodulerna för att ladda moduler snabbare i webbläsaren.

Kärnmoduler, filmoduler och externa nodemoduler

I node.js finns det tre viktiga huvudmoduler; kärnmoduler, filmoduler och externa nodemoduler. Vi börjar med filmodulen först eftersom den är lättare att förstå.

• Filmodul:
  Till skillnad från de andra två modellerna är filmodellen en modell baserad på relativ sökväg. Varför? Låt oss säga att du skulle exportera en modul via följande syntax:

 module.exports = foo { 'something' : 123 } ; 

 var foo = function () { console.log('foo called'); };

var b = function () { console.log('b called'); }; 

module.exports = { b : b };

module.exports.bar = function () {console.log('bar called');}; 

module.exports.bas = function () {console.log('bas called');};

Sättet på vilket moduler laddas eller importeras till filer skiljer sig ganska mycket från modulerna core och external_node, vilket är anledningen till att de två andra modulerna också kallas icke-relativt baserade moduler.

Observera att det finns olika sätt att exportera moduler/filer i node.js. Anonym funktion är ett annat sätt att exportera en modul från en fil.

• Kärnmoduler:
  Nästa moduler som innehåller de tre huvudmodulerna i node.js är kärnmodulerna. Kärnmoduler är icke-relativt baserade moduler. De skiljer sig mycket från filmoduler, särskilt när du kräver (eller importerar) moduler i filer.

Till exempel, om vi skulle konsumera path-modulen i node.js, som korrigerar snedstreck för att vara OS-specifika, tar hand om . och .. i sökvägen och även tar bort dubbla snedstreck, skulle vi inte inkludera den relativa sökvägen:

var require = require('path') console.log (path.normalize ('/foo/bar/......'));

• external_node-moduler:
  Dessa moduler ligger någonstans mellan kärnmoduler och filbaserade moduler. external_node-moduler är ganska lika filbaserade, särskilt när du exporterar en modul.

module.exports = function () {console.log('called node modules!');} 

När du laddar in moduler blir de dock ganska olika.

var bar = require('bas');bas(); // 

Därutöver tillhandahåller node.js några viktiga globala med användbara funktioner, som vi inte kommer att diskutera i detalj. timer,console, _filename och_dirname, och process är alla exempel på viktiga globals i node.js. Till exempel är _filename och _dirname tillgängliga i varje fil och ger tillgång till hela sökvägen och katalogen för den aktuella modulen.

Nu när vi har en kort förståelse för moduler i node.js går vi vidare till huvudaspekten, där vi skiljer på CommonJS och AMD-moduler. Vi kommer att ta itu med problemen ”varför Common.js är så långsam när det gäller att ladda moduler från webbläsaren” och ”hur vi kan konvertera den via browserify för att ärva vissa funktioner från AMD och Require.js”. .

Introduktion till CommonJS och AMD

 CommonJS is a great module for the server side environment, especially when you have immediate access to the filesystem. However, using the same module system in the browser may be less reliable and extremely slow. 

För exempel kan vi fundera på hur de två modulerna laddas i serversidemiljön:

var foo = require('./foo');var bar = require('./bar');// more code here 

Om vi tittar på exemplet ovan anses det vara en bra praxis på serversidan när en modul laddas medan den andra modulen väntar på att en annan modul ska analyseras.

Med andra ord, när modulen foo laddas kommer bar inte att analyseras eller bearbetas förrän foo har laddats av helt. Inte ens servern kanske känner till bar-modulen förrän den är klar med foo-modulen.

Att använda samma modulsystem i webbläsaren anses inte vara en bra idé eftersom varje modulsystem skulle behöva utlösa en HTTP-förfrågan till servern. Detta är mycket mindre effektivt och mindre tillförlitligt i servermiljön. Det försämrar användarupplevelsen på klientsidan. Detta problem skulle kunna lösas genom asynkron laddning av moduler.

Det är här AMD kommer in i bilden. AMD, även känt som asynkron moduldefinition, infördes för att stödja asynkron laddning av moduler i webbläsaren –
det löser så småningom den långsamma hastigheten för laddning av moduler i webbläsaren. I linje med innebörden av ”asynkron” utlöses moduler vid olika tidpunkter.

För att exportera något i en fil i AMD behöver vi helt enkelt inkludera en callback-funktion och returnera den från en define callback-funktion. Här är ett exempel:

 define(, function () { var foo = function () { console.log ('foo was called');}; return foo; // function foo is exported});

Som syntaxen för exportvariabler i node.JS tar define-funktionen också ett särskilt argument som heter exports, vilket är ganska likt det i node.JS.

define(, function (exports) {var bas = exports.log = function () {console.log ('bas.log was called'); };});

För att göra det möjligt att ladda två moduler i webbläsaren måste vi ladda ner och installera RequireJS. Kom ihåg att detta bara är ett alternativ som hindrar utvecklare från att använda node.JS-kod i webbläsaren.]

Varför behöver vi RequireJS för att kunna ladda moduler via den asynkrona moduldefinitionen?
Här är anledningen: eftersom Define-funktionen, som är en del av koden nedan (som visar oss hur vi kan ladda mer än en modul i webbläsaren via AMD), inte är inhemsk i webbläsaren. Därför är det bästa alternativet att få tillgång till den från ett bibliotek från en tredje part. RequireJS är helt enkelt en javascript-fil som du inkluderar i ditt projekt.

define(, function(foo, bar){ //more code here// more code here }); 

Så konverterar du node.js till webbläsarkod:

Nu ska vi se hur vi kan konvertera CommonJS för att bli kompatibla med AMD/RequireJS via browserify. Konvertering av CommonJS via browserify gör att node.js kan ladda moduler i webbläsaren på samma sätt som AMD/RequireJS.

Låt oss installera browserify via följande kod. Se till att du är ansluten till internet under installationen. Det med bindestreck skrivna g betyder helt enkelt global.

npm install –g browserify

Du kan skapa moduler, namnge dem som clientJS eller något annat namn som du föredrar, och så småningom konvertera dem till AMD/RequireJS med hjälp av browserify.

module.exports = function () {console.log('bas was called');}

exports.log = function () {console.log('bar.log was called');}

Nu, för att konvertera ovanstående kod så att den blir AMD-kompatibel, med andra ord för att ladda moduler asynkront, måste vi göra det via följande kommandoradsargument:

browserify client.js -o amdmodule.js

Du kan tilldela valfritt namn som du föredrar som klient. Det ska inte alltid vara client.js men client.js är också att föredra. Kom ihåg att det bara är en fil. Dessutom kan du läsa mer konfiguration om browserify på http://browserify.org/.

Slutord:

Slutligt bör du notera att inte alla node.JS-moduler kan konverteras så att de fungerar effektivt i webbläsaren. De som är beroende av funktioner som är tillgängliga på serversidan kommer inte alls att fungera i webbläsaren.

Jag har just introducerat AMD/RequireJS som en lösning som tillåter asynkron laddning av moduler i webbläsaren, vilket anses vara en bra metod. Att ladda moduler asynkront är mycket snabbare och mer tillförlitligt än att använda CommonJS i webbläsaren.