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?
javascript
node.js
commonjs
Xiao Peng - ZenUML.com
źródło
źródło
module.exports
.exports
, na przykład github.com/tj/consolidate.js/blob/master/lib/consolidate.js ?module.exports
, nigdy nie będzie źle, ale można użyćexports
, jeśli nie jesteś zastąpienie domyślnego eksportowany obiekt, to znaczy, jeśli po prostu dołączyć właściwości tak:var foo = require('foo').foo
. Tęfoo
właściwość można wyeksportować w następujący sposób:exports.foo = ...
i oczywiście również za pomocąmodule.exports
. To osobisty wybór, ale obecnie go używammodule.exports
iexports
odpowiednio.Odpowiedzi:
module
jest zwykłym obiektem JavaScript zexports
właściwością.exports
jest zwykłą zmienną JavaScript, którą można ustawić namodule.exports
. Na końcu pliku node.js po prostu „powróci”module.exports
dorequire
funkcji. Uproszczony sposób wyświetlania pliku JS w węźle może być następujący:Jeśli włączysz właściwość, na
exports
przykładexports.a = 9;
, która również zostanie ustawiona,module.exports.a
ponieważ 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 wtedyexports
imodule.exports
są tym samym przedmiotem.Ale jeśli ustawisz
exports
na coś nowego, to nie będzie już ustawionemodule.exports
, takexports
imodule.exports
nie są już tego samego obiektu.źródło
module.exports
to także: nodejs.org/api/modules.html#modules_module_exportsOdpowiedź 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
powyższy kod jest zawinięty jako IIFE (Natychmiastowe wywołanie funkcji) w kodzie źródłowym nodejs w następujący sposób:
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
wyjście będzie
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
wyjście będzie
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 :)
źródło
Ponadto jedna rzecz, która może pomóc zrozumieć:
math.js
client.js
Świetnie, w tym przypadku:
Zatem domyślnie „to” jest w rzeczywistości równe module.exports.
Jeśli jednak zmienisz implementację na:
math.js
W takim przypadku będzie działać dobrze, jednak „to” nie jest już równe modułowi. Eksportuje, ponieważ utworzono nowy obiekt.
A teraz to, co zwróci wymaganie, jest zdefiniowane w module. Eksportuje, a nie eksportuje.
Innym sposobem na to byłoby:
math.js
Lub:
math.js
źródło
Odpowiedź Rene na temat związku między
exports
imodule.exports
jest 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.
źródło
module.exports
iexports
to tylko osobne zmienne inicjowane odwoływać się do tego samego obiektu. Jeśli zmienisz to, do czego odwołuje się jedna zmienna, dwie zmienne nie będą już odnosiły się do tej samej rzeczy. Wiersz powyższego kodu zapewnia, że obie zmienne są inicjowane w tym samym nowym obiekcie.myTest.js
exports
imodule.exports
są takie same i odnoszą się do tego samego obiektu. Możesz dodać właściwości na dwa sposoby, zgodnie ze swoją wygodą.źródło