Mustache.js: 添加选项：未知变量警告

在本地开发时喜欢其他框架的这个功能，所以从我那里+1！ 我认为重要的是它对性能的影响最小甚至没有。 也许在保持核心不变的情况下甚至可行？ 例如，通过覆盖一些内部方法来在开发时启用这种行为。

也许是使用mustache.js构建的mustache.dev.js mustache.js和包含检查逻辑的函数覆盖？

我更喜欢硬错误，例如，当与 Express 一起使用时，它会变成 500 响应，而不仅仅是某个地方的日志，而最终用户看到的是错误呈现的页面（可能非常不正确地呈现，取决于丢失的方式）应该使用变量）； 这在生产中可能比在本地开发中更有用，这取决于您的 500 页的好坏与错误呈现的页面对您的应用程序功能的影响。 使用节仍然可以允许模板忽略丢失的变量，即使是直接使用的硬错误。 任何需要记录问题的更高级别的使用都在日志系统的控制之下，所以我们不必担心，比如说，Mustache 的内部警告机制会破坏测试运行程序的输出或类似的东西。

我在https://github.com/ScottFreeCode/mustache.js有一个工作原型，虽然我可以使用一些帮助来弄清楚如何为它编写测试。

嗯，所以使用对象的存在作为if ( {{#thing}} ) 会抛出错误？ （我觉得这很常见）

或者只有变量的实际呈现（ {{ id }} ）会引发错误？ 你在想什么？

编辑：非常酷的功能，我会+1 在专业中默认启用，以防它最终不会成为麻烦。

在我看来，第一个应该是错误，第二个应该是“警告”。
对于两者，我想知道有一个缺失值。

尽管在第二种情况下它在技术上可能不会中断，但它可能会对页面产生巨大影响。

另外，反过来会很好：未使用的变量......但我认为这会产生更大的影响！ :D

2016 年 11 月 8 日 14:19，David da Silva [email protected]写道：

嗯，所以使用对象的存在作为 if ({{#thing}}) 会抛出错误？ （我觉得这很常见）

或者只有变量 ({{ id }}) 的实际呈现会引发错误？ 你在想什么？

—
您收到此消息是因为您创作了该线程。
直接回复本邮件，在GitHub上查看https://github.com/janl/mustache.js/issues/599#issuecomment -259133973，或者将线程静音https://github.com/notifications/unsubscribe-auth/ AJ8FmSptdhysYrQpg1ODkIrm12A_TXcYks5q8HbbgaJpZM4J8lKe。

在我看来，第一个应该是错误，第二个应该是“警告”。
对于两者，我想知道有一个缺失值。

@MatthijsZw我明白了。 我只记得你可以为属性存储一个null值，这将是一件好事，因此不会发生异常。 （在if案例中特别提到这一点）

编辑：我目前的立场是我更愿意在两者上都犯错。 我更喜欢一致的行为，并且您会强制使用null来处理空缺失值，我认为这是可取的。

另外，反过来会很好：未使用的变量......但我认为这会产生更大的影响！ :D

我认为以某种方式获取模板期望的数据的架构并使用它来生成 GraphQL 查询......或类似的东西会很酷。

进一步反思，我认为这里的部分问题是丢失的数据无效_因为_——因此_只有如果_——模板是_期望_该数据。 因此，模板只会简单显示的缺失数据对于该逻辑总是无效的，但可以想象的是，模板可能在一个地方期望某个数据可用并将其分支为某种真/假标志（所以它是无效，如果它不是像丢失那样虚假，因此不满足该期望），但在另一个情况下，它可能期望数据可能可用或可能不可用，并根据它是否可用进行分支（在这种情况下，它永远不会无效）。

从这个角度来看，使用null来控制这对我来说并没有多大意义：

• 如果数据是错误的——不符合预期——我们怎么能期望错误的数据来控制处理错误数据的模板行为？
• 无论如何，期望确实存在于模板中。
• null可能是真实性分支的假值，这些分支期望数据并认为数据丢失无效，但这仍然让我们需要精确地确定是否提供了数据，因为我们预计数据可能不会被填充（甚至不使用null ，除非它来自使用null来丢失数据的源，例如 SQL——实际上，这表明是否将null视为缺失或不应该根据数据源进行配置）。

我们需要的是两种类型的分支，用于对模板部分的不同期望。 据我所知，这是不幸的，因为与语言无关的 Mustache 规范虽然允许（但不强制）配置丢失的数据是否是错误的，但据我所知，对于不同类型的分支没有任何内容在这一点上会有所不同。 唔...

另一方面，我目前认为无关/多余/未使用的数据实际上并不是数据无效的问题，而是模板无效的问题，如果它在应用程序/数据/模型期望它被使用。 也就是说，如果某些东西可能有用，但模板可以决定它是否相关，那么模板是否打印这些东西并不重要，但是如果某些东西确实_需要_显示给用户，那么如果模板没有' t 显示它是一个错误。 作为一种逆转，期望位于模板之外（在模型中？），而未能满足该期望的无效在于模板。 我想最好单独解决这个问题。

我想，以上是强烈的意见，但持有的意见很弱。

IMO 将null值解释为不存在的值是错误的。

{ name: null }

该对象的name属性值为假，因此永远不应被视为无效，因此不应成为抛出的理由。

更合适的检查是检查请求的属性是否已定义，就像我们在mustache.hasProperty() 中所做的那样。

但在另一种情况下，它可能期望数据可能可用也可能不可用，并根据它是否可用进行分支（在这种情况下，它永远不会无效）。

我想传达的是，如果您根据键X分支（例如{{#X}} ，则提供的数据应该具有键X ，可以是真实的或假值，但绝对不是undefined 。

• null暗示“是的，我知道没有价值。我明确指出没有价值”。
• undefined主要意味着键X甚至没有定义（如果你定义一个值为undefined的键，你最好使用null ） . 如果未定义键，则可能是因为“懒惰”地声明数据（例如，在缺少对象引用时不使用null ）或由于人为错误（错别字、错误、混淆）

所以，在这种情况下，我会看到抛出错误的好处。 （尝试在值为undefined的键上进行分支）

在另一种情况下，尝试呈现undefined或null ，不确定是否有任何用例。 也许在那一个上也有错误。

除非它来自对缺失数据使用 null 的源，例如 SQL

Afaik，Mustache 的哲学不是按原样使用模型，而是从它们生成“视图”。 您可以添加null ，以防您的提供者不知何故没有。

我目前认为无关/多余/未使用的数据实际上并不是数据无效的问题，而是模板无效的问题，如果在应用程序/数据/模型期望它时不使用该数据使用

嗯，我认为不使用所有提供的数据是很常见的。 我提出这个想法主要是为了工具的细节，比如我建议的 GraphQL 查询生成。

如果某些东西确实需要向用户显示，那么如果模板没有显示它，那就是一个错误

但是谁/什么决定什么“真正需要向用户显示的东西”？ 我猜的模板编写者？ 如果你强迫人们使用视图中的所有数据，那么你就是在强迫他们为他们打算呈现的每个模板生成一个定制的视图。

请注意：我的用例是没有分支的手动设置。

我让“其他人”手动创建数据（事件），在这种情况下，我无法验证他们是否填写了所有字段或在变量名称中打错了字。

我的模板会说“{{ event.name }} on {{ event.date }}”。 在这种情况下，缺失值会创建一个可怕的页面。
所有字段都是必需的，因此添加不显示 {{ event.date }} 的逻辑是没有意义的。

在这种情况下，“未使用”变量也很值得了解，以仔细检查拼写错误或他们添加的项目，认为它们会“神奇地”出现在页面上:)

我确信这个用例在某种程度上违反了 Mustache 的意识形态，但这是一个真实的场景。
对于两种情况（缺失值 + 未使用的值）生成警告都会很棒。

2016 年 11 月 9 日 10:53，David da Silva [email protected]写道：

但在另一种情况下，它可能期望数据可能可用也可能不可用，并根据它是否可用进行分支（在这种情况下，它永远不会无效）。

我想传达的是，如果您根据键 X 进行分支（例如 {{#X}}，则提供的数据应该具有键 X 的值，可以是真值或假值，但绝对不是未定义的。

null 意味着“是的，我知道没有价值。我明确地标记了没有价值”。
undefined 主要意味着键 X 甚至没有定义（如果你定义一个值为 undefined 的键，你最好使用 null ）。 如果未定义键，则可能是因为“懒惰”地声明数据（例如，在缺少对象引用时不使用 null）或由于人为错误（错别字、错误、混淆）
所以，在这种情况下，我会看到抛出错误的好处。 （尝试在值为 undefined 的键上进行分支）

在另一种情况下，尝试呈现 undefined 或 null，不确定是否有任何用例。 也许在那一个上也有错误。

除非它来自对缺失数据使用 null 的源，例如 SQL

Afaik，Mustache 的哲学不是按原样使用模型，而是从它们生成“视图”。 如果您的提供者不知何故没有，您可以添加空值。

我目前认为无关/多余/未使用的数据实际上并不是数据无效的问题，而是模板无效的问题，如果在应用程序/数据/模型期望它时不使用该数据使用

嗯，我认为不使用所有提供的数据是很常见的。 我提出这个想法主要是为了工具的细节，比如我建议的 GraphQL 查询生成。

如果某些东西确实需要向用户显示，那么如果模板没有显示它，那就是一个错误

但是谁/什么决定什么“真正需要向用户显示的东西”？ 我猜的模板编写者？ 如果你强迫人们使用视图中的所有数据，那么你就是在强迫他们为他们打算呈现的每个模板生成一个定制的视图。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看https://github.com/janl/mustache.js/issues/599#issuecomment -259374603，或者将线程静音https://github.com/notifications/unsubscribe-auth/ AJ8FmcFicDWYjSqibyWac-Sqjg-iFetnks5q8ZgqgaJpZM4J8lKe。

我确信这个用例在某种程度上违反了 Mustache 的意识形态，但这是一个真实的场景。 对于两种情况（缺失值 + 未使用的值）生成警告都会很棒。

两者似乎都可行。 它可能对 CI 有用。

我更喜欢直接在视图中查看参数以进行调试。

我的用例有点不同：我使用 Mustache 使用 Gulp 转换 Terraform 模板。 缺少变量会导致实例无法正确启动，尤其是在替换自由格式字符串时。 我想出了一个快速的猴子补丁来获得这个功能，但它并不理想：

var mustache = require("mustache");

var errors = [];
var lookup = mustache.Context.prototype.lookup;

mustache.Context.prototype.lookup = function(name) {
    var value = lookup.bind(this)(name);

    if (value === undefined) {
        console.error("Unknown symbol", name);
        errors.push(name);
    }

    return value;
}

var render = mustache.render;

mustache.render = function(template, view, partials) {
    var result = render.bind(this)(template, view, partials);

    if (errors.length > 0) {
        throw {message: "Unknown symbols: " + errors.join(", ")};
    }

    return result;
}

笔记：

• 它不会为您提供行号或完全限定的符号名称
• 如果您在多线程环境中工作，这可能是完全不安全的

然而，它对我的​​目的很有效，我相信如果需要，有人可以调整它。

在任何类型的配置管理环境中使用 mustache 作为模板引擎都需要在缺少变量时出现硬错误。 我有一个类似于@steverukuts的用例，用于转换 kubernetes 部署文档。 在这个用例中，缺少变量总是错误。

@stefaneg在写了几个月之后，实际上我发现 Terraform 支持以 JSON 格式编写的配置，所以现在我使用它而不是使用 Mustache。 这更好，更可编程。 我们现在已经弃用了 Mustache，它将在我们的部署管道的下一个版本中删除。

查看 Kubernetes 部署文档后，我发现这些是 YAML 文件。 大多数编程语言都有可以读写 YAML 的库，所以我建议你这样做。 从我的实验中，我了解到当您尝试操作机器可读格式时，您几乎总是有比 Mustache 更好的选择。

请注意：虽然我不再使用 Mustache 做任何事情，但我仍然认为这是一个有效的功能请求。

解决方案是使用handlebars ，它支持相同的语法，并且还有一个严格的选项，这正是这个用例所需要的。

@steverukuts如果您有需要支持的预定操作，特别是如果您需要在其中内置一些看法是正确的。 对于开放式配置工具，这会很快变得过于不灵活，因此需要模板。 尝试编写一个支持在任意位置插入任意值的工具......你很快就会拥有一个模板引擎。

过去几年，我们一直在使用kontemplate来配置 Kubernetes 资源。 它基本上是 go 模板引擎，具有来自该项目中sprig和自定义函数的一些方便的功能。 例如，它是一种比 helm 更轻量级的方法。

关于上述讨论； 它也会在未知变量上爆炸。

解决方案是使用handlebars ，它支持相同的语法，并且还有一个严格的选项，这正是这个用例所需要的。

这个问题也迫使我使用车把。 太糟糕了，这在胡须中不受支持。