Dit bericht is voor het laatst bewerkt door Summer op 13-2-2019 om 14:04
In 2009 creëerde de Amerikaanse programmeur Ryan Dahl node.js project om de JavaScript-taal te gebruiken voor server-side programmeren.
Dit markeert de geboorte van "Javascript modulaire programmering". De complexiteit van de front-end is beperkt, en het is prima om geen modules te hebben, maar aan de serverzijde moeten er modules zijn om met het besturingssysteem en andere applicaties te communiceren, anders kan het helemaal niet worden geprogrammeerd.
Een van de belangrijkste ideeën in node-programmering zijn modules, en het is dit idee dat grootschalige engineering van JavaScript mogelijk maakt. Modulair programmeren was populair in de JS-wereld en was hierop gebaseerd, en vervolgens verschenen er aan de browserzijde ook toolkits zoals requirejs en seajs, om zo te zeggen, onder de bijbehorende specificatie, require ruled alle modulaire programmering vóór ES6, zelfs nu, voordat de ES6-module volledig was geïmplementeerd.
In CommonJS gebruikt de exposuremodule module.exports en exports, en veel mensen begrijpen niet waarom er twee blootgestelde objecten zijn, die later worden geïntroduceerd
In CommonJS is er een globale methode rescribe() die wordt gebruikt om modules te laden. Als er een wiskundemodule math.js is, kan die zo geladen worden.
Je kunt dan de methoden aanroepen die door de module worden aangeboden:
Juist vanwege de require methode die door CommonJS wordt gebruikt, is de require method die AMD en CMD later gebruikten ook gebruikt om te verwijzen naar de stijl van modules
AMD-specificatie
Bij server-side modules is het logisch dat iedereen client-side modules wil. En het is het beste dat de twee compatibel zijn, en dat een module zowel op de server als de browser kan draaien zonder aanpassingen.
Er is echter een grote beperking die de CommonJS-specificatie niet toepasbaar maakt op browseromgevingen. Toch is de code uit het vorige gedeelte zo dat als die in een browser draait, er een groot probleem zal zijn
De tweede regel math.add(2, 3) loopt na de eerste regel requirre('math'), dus hij moet wachten tot math.js lading klaar is. Dat wil zeggen, als de laadtijd lang is, stopt de hele app daar en wacht ze af.
Dit is geen probleem aan de serverzijde, omdat alle modules op de lokale harde schijf worden opgeslagen en synchroon geladen kunnen worden, en de wachttijd is de leestijd van de harde schijf. Voor browsers is dit echter een groot probleem, omdat de modules aan de serverzijde worden geplaatst, en de wachttijd afhangt van de snelheid van de internetsnelheid, wat lang kan duren, en de browser verkeert in een "suspended death"-toestand.
Daarom kunnen browser-side modules niet "synchronous" gebruiken, maar alleen "asynchronous". Dit is de achtergrond van de geboorte van de AMD-specificatie.
AMD is een afkorting voor "Asynchronous Module Definition", wat betekent "Asynchronous Module Definition". Het laadt de module asynchroon, en het laden van de module beïnvloedt de werking van de volgende statements niet. Alle statements die van deze module afhankelijk zijn, worden gedefinieerd in een callback-functie die pas wordt uitgevoerd als het laden is voltooid.
Modules moeten worden gedefinieerd met een specifieke define()-functie.
•ID: string, modulenaam (optioneel)
•afhankelijkheden: is de afhankelijke module die we willen laden (optioneel), met behulp van het relatieve pad. , let op dat het een arrayformaat is
•factory: factory-methode, geeft een modulefunctie terug
Als een module niet afhankelijk is van andere modules, kan deze direct worden gedefinieerd in de define()-functie.
Als de module ook afhankelijk is van andere modules, dan moet het eerste argument van de define()-functie een array zijn die de afhankelijkheden van de module aangeeft.
Wanneer de require()-functie bovenstaande module laadt, wordt Lib.js bestand eerst geladen.
AMD gebruikt ook de require()-instructie om de module te laden, maar in tegenstelling tot CommonJS vereist deze twee parameters:
De eerste parameter [module] is een array, en de leden daarin zijn de modules die geladen moeten worden; De tweede parameter callback is de callback-functie nadat de load succesvol is. Als je de vorige code herschrijft naar AMD-vorm, ziet het er zo uit:
math.add() is niet gesynchroniseerd met het laden van de wiskundemodule, en de browser zet geen suspensie in de animatie. Dus AMD is duidelijk beter geschikt voor de browseromgeving.
Momenteel zijn er twee hoofdbibliotheken van Javascript die de AMD-specificatie implementeren :require.js en curl.js.
|
Geplaatst op 13-02-2019 14:01:09
|
|
|
