Node.js module.exports спрямо износ

Какви са те, как да ги използваме и как да не ги използваме

(Имайте предвид, че тази статия е написана след Node.js 6.1.0)

TL; DR

  • Помислете за module.exports като променливата, която се връща от require (). Това е празен обект по подразбиране и е добре да промените нещо.
  • Износ? Е, самият „износ“ никога не се връща!Това е просто препратка към module.exports; удобна променлива, която помага на авторите на модули да пишат по-малко код. Работата с неговите свойства е безопасна и препоръчителна.
exports.method = function() {…} 
vs.
module.exports.method = function() {…}

Прост пример за модул

Първо, имаме нужда от примерна кодова база. Нека започнем с прост калкулатор:

Употреба:

Обвивка на модула

Node.js обгръща вътрешно всички изискващи () модули във функционална обвивка:

Обектът на модула

Променлива “ модул ” е обект, представляващ текущия модул. Той е локален за всеки модул и също така е частен (достъпен само от кода на модула):

Module.exports

  • Това е връзката към обекта, която се връща от извикванията require ().
  • Той се създава автоматично от Node.js.
  • Това е просто препратка към обикновен обект на JavaScript.
  • Той също е празен по подразбиране (нашият код прикачва метод “add ()” към него)

Има два начина да използваме module.exports:

  1. Прикачване на публични методи към него (както направихме в примера с калкулатора).
  2. Замествайки го с нашия потребителски обект или функция.

Защо да го заменим? При замяна можем да върнем произволен екземпляр от някакъв друг клас. Ето пример, написан в ES2015:

По-горе „калкулатор-база“ експортира клас.

Нека разширим класа „Калкулатор“ и да експортираме екземпляр този път:

Употреба:

Изнася псевдоним

  • „Export“ е просто удобна променлива, така че авторите на модули могат да пишат по-малко код
  • Работата с неговите свойства е безопасна и препоръчителна.

    (напр .: export.add = функция ...)

  • Експортът НЕ се връща от require () (module.exports е!)

Ето някои добри и лоши примери:

Забележка: Честа практика е да замените module.exports с потребителски функции или обекти. Ако го направим, но все пак бихме искали да продължим да използваме стенограмата „износ“; тогава „износът“ трябва да бъде пренасочен към новия ни потребителски обект (също направен в кода по-горе на ред 12):

exports = module.exports = {}
exports.method = function() {...}

Заключение

Променлива с име export, която не се изнася изцяло, е объркваща, особено за новодошлите в Node.js. Дори официалната документация също има малко странно отношение към него:

Като насока, ако връзката между износ и module.exports ви се струва магия, игнорирайте износа и използвайте само module.exports.

Моето мнение е, че кодът не е магия. Разработчиците винаги трябва да търсят по-задълбочено разбиране на платформите и езиците, които използват. Постъпвайки така; програмистите получават ценна увереност и знания, което от своя страна влияе положително върху качеството на кода, архитектурата на системата и производителността.

Благодаря ви, че прочетохте моя пост. Обратната връзка и мислите винаги са добре дошли в раздела за коментари.

lazlojuly

Свързани статии:

  • Дали модулите Node.js са единични?

Източници:

  • Документация на Node.js за модули

Поръчайте новата ми серия от блогове за тестване на единични модули:

Как да започнем с Unit Testing? Част 1

Предполагам, че много от нас могат да се свържат със ситуация, описана по-горе.

Място, където единичното тестване се счита за скучна работа. medium.com