Nadal jestem bardzo zdezorientowany co do CommonJS, AMD i RequireJS , nawet po dużym przeczytaniu.

Wiem, że CommonJS (wcześniej ServerJS ) to grupa do definiowania niektórych specyfikacji JavaScript (tj. Modułów), gdy język jest używany poza przeglądarką. Specyfikacja modułów CommonJS ma pewne implementacje, takie jak Node.js lub RingoJS , prawda?

Jaki jest związek między CommonJS , definicją modułu asynchronicznego (AMD) i RequireJS ?

Czy RequireJS jest implementacją definicji modułu CommonJS ? Jeśli tak, to czym jest AMD ?

RequireJS implementuje API AMD (źródło) .

CommonJS to sposób definiowania modułów za pomocą exportsobiektu, który definiuje zawartość modułu. Krótko mówiąc, implementacja CommonJS może działać w następujący sposób:

// someModule.js
exports.doSomething = function() { return "foo"; };

//otherModule.js
var someModule = require('someModule'); // in the vein of node    
exports.doSomethingElse = function() { return someModule.doSomething() + "bar"; };

Zasadniczo CommonJS określa, że ​​potrzebujesz require()funkcji do pobierania zależności, exportszmiennej do eksportowania zawartości modułu i identyfikatora modułu (który opisuje lokalizację danego modułu w stosunku do tego modułu), który jest używany do żądania zależności ( źródło ). CommonJS ma różne implementacje, w tym Node.js , o których wspomniałeś.

CommonJS nie został specjalnie zaprojektowany z myślą o przeglądarkach, więc nie pasuje zbyt dobrze do środowiska przeglądarki ( naprawdę nie mam na to źródła - tak po prostu jest wszędzie, w tym strona RequireJS ) . Najwyraźniej ma to coś do zrobić z ładowaniem asynchronicznym itp.

Z drugiej strony RequireJS implementuje AMD, które jest zaprojektowane tak, aby pasowało do środowiska przeglądarki ( źródła ). Najwyraźniej AMD zaczęło jako wydzielenie formatu CommonJS Transport i przekształciło się we własny interfejs API definicji modułów. Stąd podobieństwa między nimi. Nowa funkcja AMD to define()funkcja, która pozwala modułowi zadeklarować swoje zależności przed załadowaniem. Na przykład definicja może wyglądać następująco:

define('module/id/string', ['module', 'dependency', 'array'], 
function(module, factory function) {
  return ModuleContents;  
});

Tak więc CommonJS i AMD to interfejsy API definicji modułów JavaScript , które mają różne implementacje, ale oba pochodzą z tego samego źródła.

• AMD jest bardziej odpowiedni dla przeglądarki, ponieważ obsługuje asynchroniczne ładowanie zależności modułów.
• RequireJS jest implementacją AMD , a jednocześnie stara się zachować ducha CommonJS (głównie w identyfikatorach modułów).

Aby jeszcze bardziej Cię zdezorientować, RequireJS, będąc implementacją AMD, oferuje opakowanie CommonJS, dzięki czemu moduły CommonJS można niemal zaimportować bezpośrednio do użycia z RequireJS.

define(function(require, exports, module) {
  var someModule = require('someModule'); // in the vein of node    
  exports.doSomethingElse = function() { return someModule.doSomething() + "bar"; };
});

Mam nadzieję, że to pomoże w wyjaśnieniu!

CommonJS to coś więcej - to projekt definiujący wspólny interfejs API i ekosystem dla JavaScript. Jedną częścią CommonJS jest specyfikacja modułu . Node.js i RingoJS to środowiska wykonawcze JavaScript po stronie serwera i tak, oba implementują moduły w oparciu o specyfikację modułu CommonJS.

AMD (Definicja modułu asynchronicznego) to kolejna specyfikacja modułów. RequireJS jest prawdopodobnie najpopularniejszą implementacją AMD. Jedną z głównych różnic w stosunku do CommonJS jest to, że AMD określa, że ​​moduły ładowane są asynchronicznie - to znaczy moduły ładowane są równolegle, w przeciwieństwie do blokowania wykonywania przez oczekiwanie na zakończenie ładowania.

Z tego powodu AMD jest częściej używane w programowaniu JavaScript po stronie klienta (w przeglądarce), a moduły CommonJS są zwykle używane po stronie serwera. Można jednak użyć dowolnej specyfikacji modułu w dowolnym środowisku - na przykład RequireJS oferuje wskazówki dotyczące uruchamiania w Node.js, a browserrify to implementacja modułu CommonJS, którą można uruchomić w przeglądarce.

Krótka odpowiedź brzmiałaby:

CommonJS i AMD to specyfikacje (lub formaty) dotyczące sposobu deklarowania modułów i ich zależności w aplikacjach javascript.

RequireJS to biblioteka programu ładującego skrypty, która jest zgodna z AMD, a curljs jest kolejnym przykładem.

Zgodny z CommonJS:

Zaczerpnięte z książki Addy Osmani .

// package/lib is a dependency we require
var lib = require( "package/lib" );

// behavior for our module
function foo(){
    lib.log( "hello world!" );
}

// export (expose) foo to other modules as foobar
exports.foobar = foo;

Zgodny z AMD:

// package/lib is a dependency we require
define(["package/lib"], function (lib) {

    // behavior for our module
    function foo() {
        lib.log( "hello world!" );
    }

    // export (expose) foo to other modules as foobar
    return {
        foobar: foo
    }
});

Gdzie indziej moduł może być używany z:

require(["package/myModule"], function(myModule) {
    myModule.foobar();
});

Niektóre tło:

W rzeczywistości CommonJS to znacznie więcej niż deklaracja API i zajmuje się tym tylko jego część. AMD zaczęło jako projekt specyfikacji formatu modułu na liście CommonJS, ale pełny konsensus nie został osiągnięty, a dalszy rozwój formatu został przeniesiony do grupy amdjs . Argumenty, wokół których formatu jest lepszy, wskazują, że CommonJS próbuje uwzględnić szerszy zestaw problemów i że lepiej nadaje się do rozwoju po stronie serwera, biorąc pod uwagę jego synchroniczny charakter, oraz że AMD lepiej nadaje się do programowania po stronie klienta (przeglądarki), biorąc pod uwagę jego asynchroniczny charakter i fakt, że ma swoje korzenie w implementacji deklaracji modułu Dojo.

Źródła:

• RequireJS - Dlaczego AMD?
• Addy Osmani - Nauka wzorców projektowych JavaScript - Nowoczesne wzorce projektowe JavaScript

Cytowanie

AMD :

• Jedno podejście do przeglądarki
• Wybór zachowania asynchronicznego i uproszczonej kompatybilności wstecznej
• Nie ma żadnej koncepcji File I / O.
• Obsługuje obiekty, funkcje, konstruktory, łańcuchy, JSON i wiele innych typów modułów.

CommonJS :

• Jedno podejście do serwera
• Zakładając zachowanie synchroniczne
• Obejmują szerszy zestaw problemów, takich jak I / O, system plików, obietnice i wiele innych.
• Obsługuje nieopakowane moduły, może czuć się trochę bliżej specyfikacji ES.next/Harmony , uwalniając cię od opakowującego definiowania (), które AMDwymusza.
• Obsługuj tylko obiekty jako moduły.

Całkiem normalne jest organizowanie programu JavaScript w kilka plików i wywoływanie go child-modulesz main js module.

Chodzi o to, że JavaScript tego nie zapewnia. Nawet dzisiaj w najnowszych wersjach przeglądarek Chrome i FF.

Ale czy w JavaScript jest jakieś słowo kluczowe, które wywołuje inny moduł JavaScript?

To pytanie może być dla wielu totalnym upadkiem świata, ponieważ odpowiedź brzmi „ nie” .

W ES5 (wydany w 2009) JavaScript nie miał słów kluczowych, takich jak import , to albo wymagają .

ES6 oszczędza dzień (wydany w 2015 r.) Proponując słowo kluczowe importu ( https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Statements/import ), ale żadna przeglądarka tego nie implementuje.

Jeśli używasz Babel 6.18.0 i transpiluj tylko z opcją ES2015

import myDefault from "my-module";

dostaniesz requireponownie.

"use strict";
var _myModule = require("my-module");
var _myModule2 = _interopRequireDefault(_myModule);
function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }

Wynika to z faktu require, że moduł zostanie załadowany z Node.js. Node.js obsłuży wszystko - od odczytu pliku na poziomie systemu po zawijanie funkcji do modułu.

Ponieważ w JavaScript funkcje są jedynymi opakowaniami reprezentującymi moduły.

Jestem bardzo zdezorientowany co do CommonJS i AMD?

Zarówno CommonJS, jak i AMD to tylko dwie różne techniki przezwyciężenia „defektu” JavaScript w celu inteligentnego załadowania modułów.