这个问题是关于ES6而不是全局变量
当新的ES2015 export
或export default
被引入时。它们是为了使您可以使用import
在其他地方导入/获取相同的变量,值或项目。所以我有一个简单的问题。 为什么我们应该使用导出和导入而不是仅仅创建一个类的简单对象并通过它获取项目或只是制作静态或全局变量?(如果我遗漏了某些内容或者我被问到,请纠正我这个问题在评论中不正确,而不是投票,这将更加值得赞赏。谢谢!)
编辑:我知道它可以用来使你的代码更清晰,并且可以轻松地将代码放入多个文件中,但我们假设我们有first.js
和{{1}我们想要在second.js
中获得names
中的first.js
变量。现在,您可以使用second.js
和import
执行此操作,也可以在export
中创建一个对象,然后通过该对象访问我们的变量。那么为什么使用导出和导入会更好呢?
答案 0 :(得分:1)
import
与{{1}}一起使用(您需要明确声明以后导入的内容),作为ES2015模块标准的一部分。
在实现这些标准模块之前,将Javascript代码拆分为多个文件而不是让所有对象污染全局对象只能使用非标准模块定义和/或RequireJS之类的模块加载器。最简单的情况是将代码包装在Immediately Invoked Functions中。 ES6 / 2015只是标准化Javascipt模块。
现在你问为什么不在许多文件中都有Javascript对象?答案是namespacing
答案 1 :(得分:0)
实际上 - 你说得很好。
命名空间的东西在 C++ 中。有很多人认为在他们使用的所有东西前面都有一个命名空间指示器很酷。
因此,与其说 { cout << my_string << endl; }
,不如说他们的整个程序都有 { std::cout << my_string << std::endl; }
。
有时您会看到类似 { disk::io::byte::bit::atom::neutron::quark::say_hi(2) }
的内容。而且,写这篇文章的人认为他是一个超级开发者。
但是,由于它们是纯粹的,因此您更有可能看到 { std::cout << myString << endl; }
,因为驼峰式大小写比人类可读的字符串更优先。
现在,在 node.js 中,我总是在做类似 const ClassFromMod = require('mod-with-class')
的事情。在文件中,您必须说 module.exports = ClassDeclaredInHere
。我总是这样做,因为真的,有没有其他方式提供?
或者您可以这样做const {ClassFromMod} = require('mod-with-class')
。
那么你必须拥有,module.exports.ClassFromMod = ClassDeclaredInHere
。
所以,在浏览器中做同样的事情是可以的。但是,现在全局上下文和本地上下文更难处理 - 真的。必要时在模块之间共享东西会更难一点。但是,不用担心几乎所有时间人们都会正确地划分他们的模块。那是因为他们是人——实际上是那种比负责核反应堆的人更谨慎的人——因为这些人会做一些网络编程。因此,在划分模块时没有切尔诺贝利。对吗?
现在,您可以进入类定义了。而且,类本身就是一个命名空间。
那么,为什么没有类的全局注册表?只是可能不同的公司(个人开发人员)会对两个远程不同的类使用相同的名称。但是,很可能会有办法解决这个问题。
一种方法可能是将类分配给用途(有点命名空间)。但是,它可能更分类。像具有汽车功能的东西的“引擎”,或运行脚本的东西的“引擎”。编程语言可能有“在这里谈论汽车”之类的东西。那会是什么样子?
start>> talking about cars <
let bval = engine.rev()
if ( bval ) {
<about scripts> engine.run("small program")
}
<<stop talking about car
这是一个想法。看着它,我不喜欢它。这有点像许多语言使用的“with”。
因此,随着对编程环境的新限制,您会遇到错误和范围问题,这些问题会增加您漫长的一天。但是,您应该明白,从某种意义上说,从清晰的思维中提出的问题是被一小群有能力的人压制的。而且,你可以为他们倒垃圾。
那么,如何通过特征识别对象并启用某种平面命名空间管理呢?可以由人工智能驱动。三十年前就可以做到。但是,现在就是现在。但是,未来的存在是为了纠正过去的错误。