Różnica między „module.exports” a „eksportami” w systemie modułów CommonJs

Na tej stronie ( http://docs.nodejitsu.com/articles/getting-started/what-is-require ) stwierdza się, że „Jeśli chcesz ustawić obiekt eksportu na funkcję lub nowy obiekt, musisz: użyj obiektu module.exports. ”

Moje pytanie brzmi: dlaczego.

// right
module.exports = function () {
  console.log("hello world")
}
// wrong
exports = function () {
  console.log("hello world")
}

I console.logged wynik ( result=require(example.js)), a pierwszy to [Function]drugi {}.

Czy mógłbyś wyjaśnić przyczynę? Czytałem post tutaj: module.exports vs eksportu w node.js . Jest to pomocne, ale nie wyjaśnia powodu, dla którego został zaprojektowany w ten sposób. Czy wystąpi problem, jeśli odniesienie do eksportu zostanie zwrócone bezpośrednio?

modulejest zwykłym obiektem JavaScript z exportswłaściwością. exportsjest zwykłą zmienną JavaScript, którą można ustawić na module.exports. Na końcu pliku node.js po prostu „powróci” module.exportsdo requirefunkcji. Uproszczony sposób wyświetlania pliku JS w węźle może być następujący:

var module = { exports: {} };
var exports = module.exports;

// your code

return module.exports;

Jeśli włączysz właściwość, na exportsprzykład exports.a = 9;, która również zostanie ustawiona, module.exports.aponieważ obiekty są przekazywane w JavaScript jako referencje, co oznacza, że ​​jeśli ustawisz wiele zmiennych dla tego samego obiektu, wszystkie będą tym samym obiektem; więc wtedy exportsi module.exportssą tym samym przedmiotem.
Ale jeśli ustawisz exportsna coś nowego, to nie będzie już ustawione module.exports, tak exportsi module.exportsnie są już tego samego obiektu.

Odpowiedź Renee jest dobrze wyjaśniona. Dodatek do odpowiedzi z przykładem:

Węzeł robi wiele rzeczy w twoim pliku, a jednym z ważnych jest OWIJANIE pliku. Wewnątrz kodu źródłowego nodejs zwracany jest „module.exports”. Cofnijmy się i zrozummy opakowanie. Załóżmy, że masz

greet.js

var greet = function () {
   console.log('Hello World');
};

module.exports = greet;

powyższy kod jest zawinięty jako IIFE (Natychmiastowe wywołanie funkcji) w kodzie źródłowym nodejs w następujący sposób:

(function (exports, require, module, __filename, __dirname) { //add by node

      var greet = function () {
         console.log('Hello World');
      };

      module.exports = greet;

}).apply();                                                  //add by node

return module.exports;                                      //add by node

a powyższa funkcja jest wywoływana (.apply ()) i zwraca moduł.exports. W tej chwili moduł. Eksportuje i eksportuje wskazując to samo odwołanie.

Teraz wyobraź sobie, że ponownie napisałeś greet.js jako

exports = function () {
   console.log('Hello World');
};
console.log(exports);
console.log(module.exports);

wyjście będzie

[Function]
{}

powodem jest to: module.exports jest pustym obiektem. Nie ustawiliśmy niczego w module.exports, zamiast tego ustawiamy export = function () ..... w nowym pliku greet.js. Tak więc moduł.exports jest pusty.

Technicznie eksport i moduł.eksport powinny wskazywać to samo odniesienie (to prawda !!). Ale używamy „=” przy przypisywaniu funkcji () .... do eksportu, co tworzy kolejny obiekt w pamięci. Tak więc moduł. Eksport i eksport dają różne wyniki. Jeśli chodzi o eksport, nie możemy go pominąć.

Teraz wyobraź sobie, że piszesz ponownie (to się nazywa mutacja) greet.js (odnosząc się do odpowiedzi Renee) jako

exports.a = function() {
    console.log("Hello");
}

console.log(exports);
console.log(module.exports);

wyjście będzie

{ a: [Function] }
{ a: [Function] }

Jak widać moduł. Eksport i eksport wskazują na to samo odwołanie, które jest funkcją. Jeśli ustawisz właściwość dla eksportu, zostanie ona ustawiona w module.exports, ponieważ w JS obiekty są przekazywane przez odniesienie.

Wniosek zawsze dotyczy użycia modułu. Eksportuje, aby uniknąć nieporozumień. Mam nadzieję że to pomoże. Miłego kodowania :)

Ponadto jedna rzecz, która może pomóc zrozumieć:

math.js

this.add = function (a, b) {
    return a + b;
};

client.js

var math = require('./math');
console.log(math.add(2,2); // 4;

Świetnie, w tym przypadku:

console.log(this === module.exports); // true
console.log(this === exports); // true
console.log(module.exports === exports); // true

Zatem domyślnie „to” jest w rzeczywistości równe module.exports.

Jeśli jednak zmienisz implementację na:

math.js

var add = function (a, b) {
    return a + b;
};

module.exports = {
    add: add
};

W takim przypadku będzie działać dobrze, jednak „to” nie jest już równe modułowi. Eksportuje, ponieważ utworzono nowy obiekt.

console.log(this === module.exports); // false
console.log(this === exports); // true
console.log(module.exports === exports); // false

A teraz to, co zwróci wymaganie, jest zdefiniowane w module. Eksportuje, a nie eksportuje.

Innym sposobem na to byłoby:

math.js

module.exports.add = function (a, b) {
    return a + b;
};

Lub:

math.js

exports.add = function (a, b) {
    return a + b;
};

Odpowiedź Rene na temat związku między exportsi module.exportsjest dość jasna, wszystko dotyczy odwołań do javascript. Chcę tylko dodać, że:

Widzimy to w wielu modułach węzłów:

var app = exports = module.exports = {};

Zapewni to, że nawet jeśli zmienimy module.exports, nadal będziemy mogli używać eksportu, sprawiając, że te dwie zmienne wskazują ten sam obiekt.

myTest.js

module.exports.get = function () {};

exports.put = function () {};

console.log(module.exports)
// output: { get: [Function], put: [Function] }

exportsi module.exportssą takie same i odnoszą się do tego samego obiektu. Możesz dodać właściwości na dwa sposoby, zgodnie ze swoją wygodą.