在 Meteor 中处理全局变量

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

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

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

我创建了一个新文件"lib/constants.js"并简单地做了FOO = 'bar;(注意没有关键字(。这似乎工作得很好。我发现这个解决方案是公认的答案如何在 Meteor 中的 lib/常量.js 文件中访问常量？

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

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

有什么见解吗？

是的，如果您使用的是旧版本的meteor，则可以使用set.json，但对于更新版本，我们有导入选项。

我认为模式并没有那么糟糕。不过，我会将该文件放在/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

这实际上是一种不喜欢的模式，因为使用全局变量，您无法跟踪更改的内容，并且通常构建模块化和可替换的组件要好得多。这种模式之所以成为可能，是因为 Meteor 早期还不支持imports目录/模式，您将在both、server和client之间拆分整个代码。

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

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

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

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

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

为什么全局变量被认为是不好的做法？

相关内容