在 Meteor 中处理全局变量

Question

我正在服务器和客户端上使用查询 (pub/sub)。所以我在几个不同的地方都有这样的东西。

const FOO = 'bar';
Collection.find({property:FOO})

Foo 可能会发生变化，而不是必须在不同的位置更新我的代码，我认为将其抽象为客户端和服务器都可见的全局变量可能是值得的。

我创建了一个新文件 'lib/constants.js' 并简单地做了 FOO = 'bar;（注意没有关键字）。这似乎工作得很好。我发现这个解决方案是公认的答案 How can I access constants in the lib/constants.js file in Meteor?

我的问题是这是否是 Meteor 甚至一般 JS 中所需的模式。

我知道我可以将其抽象到一个模块中，但在这种情况下这可能有点矫枉过正。我还认为使用 session/reactive 变量是不安全的，因为它可能会导致远距离操作。我什至不会考虑使用 settings.json 因为它应该只用于环境变量。

有什么见解吗？

Answer 1

这实际上是一个 b̶a̶d̶ 不受欢迎的模式，因为使用全局变量您无法跟踪发生了什么变化，并且通常构建模块化和可替换组件要好得多。这种模式之所以成为可能，是因为 Meteor 早期还不支持 imports directory/pattern，你会将整个代码拆分为 both、server 和 client.

https://docs.meteor.com/changelog.html#v13220160415

您可以在网上找到很多关于它的文章和事件 Whosebug 的答案，所以我不想重复显而易见的事情。

使用 settings.json 变量不是一种选择，因为我们可能会动态更改，那么我们的选择是什么？对我来说，我会说：

将其存储在数据库中，当然可以使用具有适当访问范围的方法发布或检索它。您也可以使用作者数据库更改的方法动态修改它。
或者，您可以尝试使用 Meteor.EnvironmentVariable。如果我说我知道如何正确使用它，那我就是在撒谎，但我已经看到它被用于几个 Meteor 项目来解决类似的情况。

https://www.eventedmind.com/items/meteor-dynamic-scoping-with-environment-variables

Why are global variables considered bad practice?

Answer 2

我不认为这种模式有那么糟糕。我会将该文件放在 /imports 中并显式导入它。

或者，您可以从服务器写入 Meteor.settings.public，例如，在启动时，这些值将在客户端的同一位置可用。您可以在没有设置文件的情况下执行此操作，这很好，因为它不需要您在开发和生产之间进行任何更改。

服务器：

Meteor.startup(() => {
  // code to run on server at startup
  Meteor.settings.public.FOO = 'bar';
});

客户：

> console.log(Meteor.settings.public.FOO);
bar

Answer 3

是的，如果您使用的是旧版本的流星，那么您可以使用 setting.json 但对于更新版本，我们有导入选项。

在 Meteor 中处理全局变量

Handling global variables in Meteor

javascript

scope

global-variables

meteor