de lazlojuly

Ce sunt, cum să le folosești și cum să nu le folosești

(Rețineți că acest articol a fost scris după lansarea Node.js 6.1.0)

TL; DR

  • Gândiți-vă la module.exports ca la variabila care este returnată din require (). Este un obiect gol în mod implicit și este bine să schimbați orice.
  • Exporturile? Ei bine, „exporturile” în sine nu sunt returnate niciodată! Este doar o referință la module.exports; o variabilă de comoditate pentru a ajuta autorii modulelor să scrie mai puțin cod. Lucrul cu proprietățile sale este sigur și recomandat.
exports.method = function() {…} 
vs.
module.exports.method = function() {…}

Un exemplu simplu de modul

În primul rând, avem nevoie de un exemplu de bază de cod. Să începem cu un calculator simplu:

Utilizare:

Înfășurarea modulului

Node.js împachetări interne toate au nevoie de module () – ed într-un wrapper de funcții:

Obiectul modulului

Variabil “modul”Este un obiect care reprezintă modulul curent. Aceasta este local pentru fiecare modul și este, de asemenea, privat (accesibil numai din codul modulului):

Module.exports

  • Este referința obiectului care este returnată din apelurile require ().
  • Este creat automat de Node.js.
  • Este doar o referință la un obiect JavaScript simplu.
  • De asemenea, este gol în mod implicit (codul nostru atașează o metodă „add ()”)

Există două moduri în care putem folosi module.exports:

  1. Atașarea metodelor publice la el (așa cum am făcut în exemplul calculatorului).
  2. Înlocuind aceasta cu obiectul sau funcția noastră personalizată.

De ce să-l înlocuiți? La înlocuire, putem returna orice instanță arbitrară a unei alte clase. Iată un exemplu scris în ES2015:

Mai sus, „calculator-base” exportă o clasă.
Să extindem clasa „Calculator” și să exportăm o instanță de data aceasta:

Utilizare:

Exportă alias

  • „Exporturi” este doar o variabilă de comoditate, astfel încât autorii modulelor pot scrie mai puțin cod
  • Lucrul cu proprietățile sale este sigur și recomandat.
    (de exemplu: exporturi.add = funcție …)
  • Exporturi NU este returnat de require () (module.exports este!)

Iată câteva exemple bune și rele:

Notă: Este o practică obișnuită să înlocuiți module.exports cu funcții sau obiecte personalizate. Dacă facem acest lucru, dar totuși am dori să continuăm să folosim stenograma „exporturilor”; atunci „exporturile” trebuie îndreptate spre noul nostru obiect personalizat (realizat și în codul de mai sus la linia 12):

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

Concluzie

O variabilă numită exporturi faptul că nu este exportat în totalitate este confuz, mai ales pentru noii veniți la Node.js. Chiar și documentația oficială are o abordare puțin ciudată:

Ca orientare, dacă relația dintre exporturi și module.exports vi se pare magică, ignorați exporturile și utilizați doar module.exports.

Ideea mea este că codul nu este magic. Dezvoltatorii ar trebui să caute întotdeauna o înțelegere mai profundă a platformelor și a limbajelor pe care le folosesc. Facand asa; programatorii câștigă încredere și cunoștințe valoroase, care la rândul lor au un impact pozitiv asupra calității codului, arhitecturii sistemului și productivității.

Mulțumesc că mi-ai citit postarea. Feedback-ul și gândurile sunt întotdeauna binevenite în secțiunea de comentarii.

lazlojuly

Surse:

Verificați noua mea serie de bloguri cu privire la testarea unității unitare:

Cum să începeți cu testarea unitară? Partea 1
Cred că mulți dintre noi ne putem referi la o situație descrisă mai sus.
Un loc în care testarea unității este considerată o corvoadă.medium.com