Node.js module.exports vs exportations

Que sont-ils, comment les utiliser et comment ne pas les utiliser

(Notez que cet article a été écrit après la version Node.js 6.1.0)

TL; DR

  • Considérez module.exports comme la variable renvoyée par require (). C'est un objet vide par défaut, et il n'y a rien de mal à changer.
  • Exportations? Eh bien, les «exportations» elles-mêmes ne sont jamais retournées!C'est juste une référence à module.exports; une variable pratique pour aider les auteurs de modules à écrire moins de code. Travailler avec ses propriétés est sûr et recommandé.
exports.method = function() {…} 
vs.
module.exports.method = function() {…}

Un exemple de module simple

Tout d'abord, nous avons besoin d'un exemple de base de code. Commençons par une simple calculatrice:

Usage:

Le wrapper de module

Node.js enveloppe en interne tous les modules require () - ed dans un wrapper de fonction:

L'objet module

La variable « module » est un objet représentant le module courant. Il est local à chaque module et il est également privé (accessible uniquement à partir du code du module):

Module.exports

  • C'est la référence d'objet qui est renvoyée par les appels require ().
  • Il est automatiquement créé par Node.js.
  • Il s'agit simplement d'une référence à un objet JavaScript simple.
  • Il est également vide par défaut (notre code y attache une méthode «add ()»)

Il existe deux manières d'utiliser module.exports:

  1. Y attacher des méthodes publiques (comme nous l'avons fait dans l'exemple de la calculatrice).
  2. En le remplaçant par notre objet ou fonction personnalisé.

Pourquoi le remplacer? Lors du remplacement, nous pouvons renvoyer n'importe quelle instance arbitraire d'une autre classe. Voici un exemple écrit dans ES2015:

Ci-dessus, «calculator-base» exporte une classe.

Étendons la classe "Calculator" et exportons une instance cette fois:

Usage:

Exporte l'alias

  • «Exports» est juste une variable de commodité pour que les auteurs de modules puissent écrire moins de code
  • Travailler avec ses propriétés est sûr et recommandé.

    (par exemple: exports.add = fonction…)

  • Les exportations ne sont PAS renvoyées par require () (module.exports l'est!)

Voici quelques bons et mauvais exemples:

Remarque: il est courant de remplacer module.exports par des fonctions ou des objets personnalisés. Si nous faisons cela, mais que nous aimerions continuer à utiliser le raccourci «exportations»; puis «exports» doit être redirigé vers notre nouvel objet personnalisé (également fait dans le code ci-dessus à la ligne 12):

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

Conclusion

Une variable nommée exports qui n'est pas entièrement exportée prête à confusion, en particulier pour les nouveaux arrivants sur Node.js. Même la documentation officielle a une vision un peu étrange:

À titre indicatif, si la relation entre les exportations et module.exports vous semble magique, ignorez les exportations et n'utilisez que module.exports.

Mon avis est que le code n'est pas magique. Les développeurs doivent toujours rechercher une compréhension plus approfondie des plates-formes et des langages qu'ils utilisent. En faisant cela; les programmeurs acquièrent une confiance et des connaissances précieuses qui à leur tour ont un impact positif sur la qualité du code, l'architecture du système et la productivité.

Merci d'avoir lu mon post. Les commentaires et les réflexions sont toujours les bienvenus dans la section des commentaires.

lazlojuly

Articles Liés:

  • Les modules Node.js sont-ils des singletons?

Sources:

  • Documentation Node.js sur les modules

Découvrez ma nouvelle série de blogs sur les tests unitaires:

Comment démarrer avec les tests unitaires? Partie 1

Je suppose que beaucoup d'entre nous peuvent se rapporter à une situation décrite ci-dessus.

Un lieu où les tests unitaires sont considérés comme une corvée. medium.com