有没有理由使用IIFE定义module.exports？ [英] Is there any reason to define module.exports using an IIFE?

问题描述

我的团队没有任何经验丰富的JS开发人员，但是我们正在Node编写一个库，并从一个真正的JS开发人员那里得到一个建议：我们应该使js更加模块化 - 不要污染全局命名空间并制作它对新来者更具可读性，并告诉我们要做以下事情：

My team doesn't have any experienced JS developers, but we are writing a library in Node and got a suggestion from a real JS developer that "We should make the js more modular - not to pollute the global namespace and to make it more readable to new-comers", and told us to do the following:

module.exports = (function(){
      return {
         nameToExpose: functionToExpose
         ...
    };
})();

而不是

module.exports.nameToExpose = functionToExpose;

如果有的话，这是什么意思？后者不会制作任何由IIFE规定的本地声明，即使它确实如此，它们将是模块文件的本地声明，而不是整个程序的全局声明 require（） s it。

What's the point of this, if any? The latter does not make any local declarations that would be scoped by the IIFE, and even if it did, they would be local to the module file and not global to the whole program that require()s it.

关于这个网站的一些谷歌搜索并没有找到任何关于这个特定问题的答案，尽管我对IIFE有许多其他的解释已阅读（以及上述评论中总结的内容）。一些测试肯定会发现后者确实不实际上在全局命名空间中放置了 functionToExpose ，尽管它的原始名称记录在函数类型本身中。 / p>

Some Googling and poking about this site does not turn up any answers on this particular question, though there are many other explanations of IIFEs that I have read (and which are summarized in the above comment). Some testing certainly reveals that the latter does not actually put functionToExpose in the global namespace, though its original name is recorded in the function type itself.

推荐答案

几乎没有区别。 Node.js的整个想法，使用 require ，有模块等，专门用于区分问题。我（小心地）说，如果你做得对，你不应该担心污染任何类型的全球范围。 module.exports 内的任何内容都存在于该模块中。

Pretty much no difference. The whole idea of Node.js, using require, having modules, etc., is specifically to separate concerns. I'd say (cautiously) that if you're doing it right, you shouldn't be needing to worry about "polluting" any sort of global scope. Anything within module.exports lives in that module.

当你处理前端的东西时，那就是当全局范围变得令人担忧时，因为如果函数或其他任何不是作用域的（即，在IIFE或其他功能块中），它可以访问全局窗口对象，其他一切都可以访问该函数。

When you're dealing with front-end stuff, that's when the global scope becomes something of a concern, because if a function or whatever isn't scoped (i.e., in an IIFE, or other function block), it has access to the global window object, and everything else has access to that function.

一个真正的JS开发人员

a real JS developer

调用某个红旗。

不污染全局命名空间使其对新手更具可读性

not to pollute the global namespace and to make it more readable to new-comers

如果你正确地模块化你的代码，那不应该是一个问题。 IIFE有一个时间和地点，但我认为没有理由将IIW中的所有内容包装在已经在模块内部中，它会以某种方式神奇地使代码更模块化或更具可读性对于新来者，而不是简单地使用像它设计的Node.js：

If you're modularizing your code correctly, that shouldn't be a concern. There's a time and a place for IIFEs, but I see no reason why wrapping everything in an IIFE, which is already inside of a module, would somehow magically make the code "more modular" or any more readable to "new comers" than by simply using Node.js like it was designed:

module.exports = function() { ... } // whatever

即使它确实如此，他们也会是模块文件的本地，而不是整个程序的全局， require（） s it。

你是对的。我不顾一切地说他的话。也许他知道一些具体的用例，他的方法过去对他很有帮助，所以我会特别问他这个问题，看看他说的是什么。除此之外，我觉得你走在正确的轨道上。

You are correct. I'd take whatever he's saying with a grain of salt. Maybe he knows of some specific use-cases where his approach has been helpful to him in the past, so I'd ask him specifically about that to see what he says. Other than that, I feel like you're on the right track.

这篇关于有没有理由使用IIFE定义module.exports？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！