这可以由助手完成。
看看这个： http :
有 ifequal 帮助器可以比较两个值。
类似的解决方案可用于您的要求。

我以前很怕那个。
我知道这样的事情可以用助手来完成......但是，我的意思是，比较东西非常基本，它应该在默认包中。

如果它被包含在包中，无论如何它都会是一个帮手。

@thany http://doginthehat.com.au/2012/02/comparison-block-helper-for-handlebars-templates/

@andriijas非常正确，它确实是一个帮手 ;) 或者不是，因为 if 块是如此基本。
谢谢你的链接。 这很有帮助，但我很想写一个覆盖原始 if 的“帮助程序”，使其成为 _proper_ if。 我确定这是可能的。 任何自尊的模板引擎都需要适当的条件格式。 把手也不例外。

您需要克服这样一个事实，即把手中将业务逻辑应用于模板的所有内容都是助手。

所有内置的，如果等都是通过 registerHelper 定义的。 查看：
https://github.com/wycats/handlebars.js/blob/master/lib/handlebars/base.js

因此，使用助手并没有什么“坏事”。 Handlebars 或多或少只是一个胡子模板编译器，为了获得额外的业务逻辑，他们使用了助手。 如果您认为您只是在使用 Rails 或其他东西时使用“helpers”这个词的经历很糟糕。

我从来没有说过“帮手”有什么问题。 只是在我看来，正确的 if 语句不应该是扩展。 帮手（同样，在我看来）是特定于 CMS 之类的东西。 助手是执行特殊操作或条件的东西。 不适合所有人的东西。 也就是说，如果它是在核心库之外定义的。 也许有点像 jQuery 插件：最基本的东西是内置的，让你开始的东西。 但是不适合所有人的东西是在核心库之外（即在插件中）定义的。 在 jQuery 术语中，一个简单的过滤器功能不会是一个插件。

if 语句（在我看来）不适用于此插件范式。 这是基本的，它是编程和模板引擎最基本的原则之一......

然后快速跟进。 这是我到目前为止所得到的：

Handlebars.registerHelper("when", function(lvalue, operation, rvalue, options) {
  console.log(arguments);
});

在我的模板中使用它，如{{#when riskfactor eq 0}}...{{/when}}我在我的控制台中得到一个[6, undefined, 0, function()]数组。 我得到的最后一个。 这就是我需要调用来处理这个 when-block 的内容。 前三个......好吧，不是那么多。 “6”其实就是“riskfactor”的值。 好吧，我可以接受。 未定义的超出了我的范围。 我认为 Handlebars 正在尝试在输入对象上对其进行评估，但这不起作用。 我想得到实际上_in_模板的东西，因为这些值与我的对象无关。

我期待像["riskfactor", "eq", "0", function()] 。 只有这样我的函数才能继续处理它。 我将如何使用“未定义”来做到这一点？

我认为 Handlebars（和其他“无逻辑”模板）的理念是模板到达的上下文应该已经被完全处理。 如果您的应用程序的内部数据结构与适合模板的数据结构不完全一致（几乎每次都是这种情况），那么您应该在渲染模板之前插入一个步骤，该步骤从您的应用程序的内部数据构建模板上下文结构。

我相信这就是人们谈论“将逻辑与表示分离”时的意图。 将 Handlebars 视为 MVC 系统的视图组件。 您的模型已经存在； 您现在必须编写的只是控制器（在本例中，它是一组从模型到视图的单向绑定）。

要回答你最近的问题，你想使用这个：

 {{#when "riskfactor" "eq" 0}}...{{/when}}

Handlebars 表达式是变量名或字符串。 如果是变量名，则在当前上下文中查找时，您将获得变量的值，而不是名称。

正如一些人指出的那样，这超出了 Handlebars 的范围。

不。
任何模板系统都可以做一个简单的比较if-else-block，而Handlebars则不能。 这使得 Handlebars 要么是可笑的不完整，要么是它的制造者不称职（这不太可能），要么是一个对模板系统任务的看法模糊不清的系统。

然后不要使用无逻辑的模板引擎。 KTHXBAI！

知道了。 涂鸦。

@thany ， @andriijas可能有点苛刻，但他是对的。 Handlebars 旨在减少逻辑。 您绝对可以制造带有电机的自行车，但许多公司乐于只制造无电机的自行车。 同样，您可以制作具有更多逻辑的模板系统，但这不是 Handlebars 想要做的事情。 抱歉，这不是您要找的。

我必须在if助手上支持@thany 。 我们应该能够将任何谓词传递给它。 无法真正限制它的实用性。 我理解无逻辑模板背后的哲学，但教条式的实现并不是真正务实的（因此存在助手，对吗？）。 我会说这更像是自行车公司增加了可变齿轮比，这是完全合理的。

顺便说一句，如果你想对机器大发雷霆并这样做，你可以创建一个助手，将谓词作为一个字符串，然后对其进行评估（并使其两次成为异端：smiling_imp:）：

Handlebars.registerHelper('when', function (predicate, options) {
    var declarations = '';
    for (var field in this) declarations += field + ' = this.' + field + ',';
    if (eval(declarations + predicate)) { return options.fn(this); }
});

{{#when 'admin || superUser'}}
    crazy go nuts
{{/when}}

@thany从最佳实践的角度来看它，你的后端应该提供所有逻辑的数据，前端（模板）应该只是渲染它......如果你的后端对象得到了比 95 更好的 JSON 表示% 案例可以通过内置条件满足http://handlebarsjs.com/#conditionals

说真的，并非所有（甚至 95%）的决策都是面向后端的。 例如，要确定要呈现哪个类名，在模板中做出该决定是完全合理的。 像这样的东西 100% 与前端/模板相关联。 后端不在乎渲染哪个类名。 或者单数/复数词呢？ 这是 if 块无法完成的另一件事。

在我看来，后端负责提供数据，并且在使用这样的丰富模板时只负责提供数据。 如果后端需要为模板可能做出决定的每种情况提供模板解析器现成的变量（考虑到这里的一些灵活性），仅从变量的数量来看，它们就会变得非常复杂，更不用说后端，使他们。

如果模板需要的每个决定都需要在后端进行另一次修改，您也可以将 HTML 放在后端。 这只是消除了模板的很大一部分目的。 与后端相关的决策处于完全不同的水平。 if 块不一定是逻辑。 它只是决定渲染什么/如何渲染。

我不敢相信这个问题需要这么长时间的讨论，一个合适的 if-block 真的太多了吗？ :(

我不会争论也不反对实现基本的比较助手，但这是非常真实的情况，我认为我无法在不使用助手或更改数据结构的情况下呈现模板：

    <select name="datatype">
      <option{{#ifeq type 'foo'}} selected="selected"{{/ifeq}}>foo</option>
      <option{{#ifeq type 'bar'}} selected="selected"{{/ifeq}}>bar</option>
      <option{{#ifeq type 'vaz'}} selected="selected"{{/ifeq}}>baz</option>
    </select>

但话又说回来，我写的助手是三行代码：

    Handlebars.registerHelper('ifeq', function (a, b, options) {
      if (a == b) { return options.fn(this); }
    });

我同意@thany ，我也不认为这应该在模板/视图之外。

为什么模板中不能有逻辑？ 车把如何提供逻辑和演示的分离？ 它仍然有一个if语句，不是吗？ 您是说if仅测试存在和/或“错误”的语句与检查（不）相等或任何其他条件的if语句没有任何不同？

唯一的——真正的——区别在于，与其他模板库不同，handlebars 在“无逻辑”的幌子下对上述逻辑的实现非常糟糕/不完整。 我很抱歉，但这完全是荒谬的。 如果您想删除逻辑，您应该完全删除if语句。 不过，您不会这样做，因为最终模板需要逻辑，原因与把手仍然具有if语句的原因相同。

因此，声明“将逻辑与表示分离”。 是错误的，不仅因为上述原因，还因为您没有从模板中删除“逻辑”，您只是将它移到模板的另一部分——即助手——也许你会得到代码重用——这将是一件好事——也许你没有，在这种情况下，你可能会得到任意数量的助手，它们的表现几乎/完全与其他助手相同，因为细微的差异本来可以通过提供正确的实现来更好if 。 这是一个好的设计决策吗？

我仍在努力理解为什么，如果某些“逻辑”本质上与特定视图绑定并且对视图本身以外的任何事物都不重要、没有意义和/或使用，那么问题究竟是什么。 对我来说，这听起来像是 mvc 极端主义/矫枉过正。

@andriijas如果我可以使用不同的模板库，我会的，不幸的是，我无法做出决定。 因此，不幸的是，任何和所有使用允许“逻辑”的模板库的建议都将被置若罔闻。

有没有人真正看过当前的 if 是如何实现的？ （也有除非哪个很好）

既然您已经了解了 if 当前是如何实现的，那么你们可能更明白为什么车把具有满足大多数人的简单而优雅的默认设置。

看看这里扩展是多么容易

https://github.com/elving/swag

https://github.com/elving/swag/blob/master/src/swag.comparisons.coffee

接受你所有的开源项目并没有提供烹饪培根所需的一切，只是提供基础。

@andriijas是的， unless只是一个if结果倒置。 我不明白这如何补偿任何东西。 感谢 helpers repo 链接，我已经写了一个 helper，不过，我不明白这如何补偿任何东西。

Handlebars 略高于 10kb（minzipped），swag 略低于 3kb（minzipped）。 因此，您将一个 10kb 的模板库添加到您的代码库中，而您还需要另外 3kb 的空间才能将逻辑添加到您的模板中。 你和其他几个人说你不应该在你的模板中使用的逻辑？

这并没有回答我的任何问题，事实上，它只是用来证明在if语句块中禁止条件测试而不是存在/虚假性是荒谬的这一点。

@andriijas我正在查看/lib/handlebars/base.js#L97 ，但我不太确定你的意思。 看起来它有某种形式的替代用法，但文档没有指定这一点。 你愿意解释吗？

@constantology有些人可能需要另外 3kb，例如您和此线程中的其他人。 在 github 上为这个 repo 加星的 3500 的其余 3500 人不太可能抱怨，因为他们已经通过添加帮助程序或在渲染模板之前完成他们的逻辑需求来解决他们的逻辑需求。

@piksel你所看到的事实是，内置的 if 只是一个助手，就像任何“插件”一样，许多人似乎有问题，认为助手速度较慢或什么的。

在您的项目中使用助手并没有错。 在一个项目中，我使用了一些 swag 助手，复制到我自己的 view_helper 文件中，因此它甚至小于 3k。

在一个主干项目中，我的视图上有一个 getTemplateData 方法，在那里我将复杂的逻辑归结为更简单的东西，使模板更清晰、更易于遵循，而且，与把手模板相比，它更容易对纯 JavaScript 进行单元测试。

@andriijas仍然没有回答我的任何问题...

在这一点上，我只是重申我已经说过的话，所以如果你觉得你实际上可以为我已经提出的任何或所有问题提供合理的答案，那么我会很高兴听到你必须回答的问题说。 :)

ps 为 repo 加注星标和/或正在使用库的人数并不一定表明库有多好。 Windows 用户的数量比 mac/linux 的总和还多，而且——取决于您查看的浏览器统计站点——与更现代的浏览器相比，使用 Internet Explorer 6、7 和 8 的用户仍然更多。 这不会使 Windows 成为比 osx 或 linux 更好的操作系统，也不会使旧版本的 Internet Explorer 优于现代标准的兼容浏览器。

这整个讨论对我来说是愚蠢的。 有一个if助手，这是逻辑。 所以整个没有逻辑的论点完全是一个稻草人。 这就像如果一辆汽车的车窗只会向下滚动，而人们抱怨并希望它们也能卷起来。 制造商表示他们不会改变它，因为这些汽车遵循严格的理念，即没有机械控制的窗户……要么你支持，要么不支持。 不应该用稻草人的论点来证明半途而废的实施是合理的。

我完全同意并理解模板中没有业务逻辑。 但是除非你在做非常简单的模板，否则你会在那里有一些视图逻辑。 由于if助手存在，Handlebars 显然认识到了这一点。 正如@thany指出的那样，通过在您的代码中添加一堆视图逻辑来解决if助手并不是答案。 我以前做过，很快就变丑了。

@mikeobrien是的，我已经在之前的评论中提到

我完全同意并理解模板中没有业务逻辑。 但是除非你在做非常简单的模板，否则你会在那里有一些视图逻辑。

很好地放置。 :^)

@constantology doh，对不起，我想我应该更好地阅读过去的评论。 ：/

我同意@constantology

FWIW 我发现 Handlebars 是一个非常优雅且编写良好的模板库。

我理解块和助手的概念很好，但是，我不认为创建一个助手来做一些小的事情——通过在核心库中支持它可以更优雅地处理它——意味着逻辑和表示的明确分离。 CSS 正在添加对条件语句的支持，其中一些已经可以通过媒体查询来实现，因此，如果它只是像@mikeobrien所说的那样只是“视图逻辑”，那么纯表示语言中的逻辑不一定是一个很大的嘘声。

我觉得这个限制——在if / unless块中缺少条件检查——使得创建优雅和封装的模板变得非常困难。

此外，我也同意有一种方法可以在通过模板解析数据之前对其进行预处理，但是，仅适用于简单的更改，而不是重新格式化整个数据结构以使其符合任何库的意愿。 为什么？

1. 如果您需要采用复杂的数据结构并创建更扁平的东西，这可能会影响解析的整体性能。
2. 基于1 ，如果对原始架构进行更改，它可能会使您的视图代码更脆弱 - 并且更难重构。
3. 它还可能使双向数据绑定更加棘手，因为您不再将原始数据结构映射到视图，从而增加可能需要跟踪更改的代码量。

这些只是我的头顶，我没有做过任何可量化的研究来支持任何这些，但它值得深思。 :^)

对于最初的问题，比较的 if 助手是错误的。 这是一个常见的场景和助手，如：
{{#ifzero count}}没有结果{{/ifzero}}
{{#ifsingular count}}1 个结果{{/ifsingular}}
{{#ifplural count}}{{count}} 结果{{/ifplural}}
会更有帮助，并将转化为他真正想做的事情。 当前的 if 语法对于（不）显示空值很有用。 也是很常见的场景。 如果有人真的需要一个 if 比较它很可能是业务逻辑，他不应该在模板中这样做。

那确实可以。
但是，我仍然认为引擎不能强迫开发人员进入某个角落，无论_原则上_是否是一个好角落。 我认为应该由开发人员决定哪个是业务逻辑，哪个是模板逻辑。

也就是说，除非无法进行比较的限制纯粹是一种以某种方式使其成为范式的技术限制。 这仅意味着在需要时永远不会添加此类功能。 我希望这不是发生的事情。

测试谢谢。 测试。 您不想在模板中进行比较，因为您无法轻松测试此逻辑。 通过数据格式化程序为您的模板创建简单的布尔值并对其进行测试比挂钩 selenium 之类的东西并在那里进行测试要简单得多。

这不仅仅是理论，这不仅仅是“原则上”。 甚至在模板中进行比较，而不测试这种逻辑，这可能是现实世界的技术债务废话。 不要编写或使用这些助手。 我还没有使用过把手的助手。 但是，如果您确实使用了帮助程序，则可以监视它并进行测试以确保它运行，因此它比内置到模板中的比较要好。

有很多不提供比较的无逻辑模板系统。 例如，在像 go 这样的强类型语言中，平等意味着什么？ Go 模板中没有比较。 有跨语言的 mustache 和 handlebar 实现，它们是相同的。

从模板中删除比较之类的逻辑不会让您的生活变得更艰难，而是让您的生活变得更轻松。 技术债务不是开玩笑，它会毁掉产品甚至公司。

来吧。
Comaprisons 并不难。 这不是火箭科学（或脑外科手术）。

在非常简单的微模板中你不需要逻辑，但如果它变得更复杂，你将需要模板中的逻辑。 有“业务逻辑”和“模板逻辑”之类的东西。 确定当某事只有一项、两项或十项时要做什么。 例如分页。 分隔线。 简单的“低于 50%”和“超过 50%”的文本，我可以继续。

事实上，其他模板引擎也没有逻辑，这并不意味着你应该盲目地遵循它们。 在我看来，他们也错了。

事实是，在某些时候，您将拥有某种您在业务逻辑中不需要或不想要的逻辑，仅仅因为它不是业务逻辑。 对于任何当前或未来模板可能需要的各种可能的比较，我无法向我的开发人员传达布尔值。

“它可以毁掉产品甚至公司”？ 严重地？
不正确的功能也可以。

它运送大多数人需要的东西并且您添加了一个助手有什么问题
你需要什么？ 每个人都赢了。 没那么难，不像火箭
科学。

如果是火箭科学： https :

2013 年 5 月 18 日星期六，thany 写道：

来吧。
Comaprisons 并不难。 这不是火箭科学（或脑外科手术）。

在非常简单的微模板中，您不需要逻辑，但如果有任何逻辑
更复杂的是，您将需要模板中的逻辑。 有这样一个
作为“业务逻辑”以及“模板逻辑”的东西。 决定做什么
当某物只有一件、两件或十件时就做。 分页，对于
例子。 分隔线。 简单的“低于 50%”和“超过 50%”的文本，我可以继续。

事实上，其他模板引擎也没有逻辑，
并不意味着你应该盲目跟随他们。 他们也错了，在我的
观点。

事实是，在某些时候，你会有某种逻辑，你只是
在业务逻辑中不需要或不想要，仅仅因为它不是业务
逻辑。 我无法向我的开发人员传达布尔值
在，对于任何当前或未来的每一种可能的比较
模板可能永远需要。

“它可以毁掉产品甚至公司”？ 严重地？
不正确的功能也可以。

—
直接回复本邮件或在Gi tHub上查看
.

大多数人_不_使用它可能是由于这里描述的问题：没有逻辑。 所以当然，大多数积极使用的人或多或少都会对它感到满意。

@thany我感觉到你，我同意你的看法。

我认为车把后面的人不想放弃这个，但是嘿，我要告诉你的是一个惊人的消息：
您可以_fork _ 项目，添加补丁并使用您自己的fork。
由于 git 的魔力，只需git pull就可以很容易地跟上新版本的步伐。

等待它，它会变得更好。

如果这恰好是一个很大的需求并且总体上更好，也许人们会开始使用您的叉子，甚至更好，把手后面的人会将您的叉子合并回原点/大师 :dancer:

有一个很好的;D

如果我愿意给自己时间，当然可以！

我绝对同意@constantology。 它的疯狂有没有逻辑的模板。 如果你想要一个无逻辑的模板，你为什么要在那里放：“if”语句代表逻辑为红色危险......没有意义。 我认为基本的比较逻辑就像汤里的盐一样。 @mikeobrien ：“不应该用稻草人的论点来证明半屁股的实施是合理的。” ：+1：

对于无逻辑的模板，有些话要说。 不过，我觉得问题是这里的每个人都将业务逻辑与视图逻辑混淆了。 业务逻辑在模板中没有位置。 时期。 然而，视图逻辑完全是另一回事。 我认为 Handlebars 意识到了这一点，这就是他们首先添加 if/else 的原因，但在此过程中他们有点困惑。

我需要知道我的数据数组是有一项还是多项，并基于此我想用逗号将它们连接起来，或者在单词中添加复数。 使用当前的 if 块，我不能这样做。

这就是我提出这个拉取请求的原因： https : http :

这个拉取请求提供了一个新的帮助器：ifTest，它接受一个 javascript 表达式，它的计算就像 javascript 给定上下文一样。 享受。

老实说，这是如此基本的功能，它让我觉得如果你想坚持这种没有将逻辑内置到框架中的心态（这对我来说似乎完全不合逻辑！）你需要重新考虑使用诸如“if”之类的逻辑术语.

我发现自己将它添加到我的很多项目中只是因为它在将诸如“0”和“1”之类的东西与布尔其他值进行比较时非常有用：

Handlebars.registerHelper('ifCond', function(v1, v2, options) {
如果（v1 === v2）{
返回 options.fn(this);
}
返回 options.inverse(this);
});

我认为让现有的“如果”功能按照它的方式工作是完全公平的，但是帮英语语言一个忙并选择另一个词（或者让它做人们期望的那样）。 当“if”一词在任何其他上下文中的表现都不像真正的 if 语句时，这感觉就像是对术语“if”的真正变态。

我想再次投票，要么完全删除if ，要么允许if接受一些基本的比较参数，例如eq 、 ne 、 gt等。你最终会得到{{#if arg1 eq arg2}} 。 当然，完全删除if对您的“模板中没有逻辑”哲学更有意义（现在更像是“模板中_大多数时间_中没有逻辑_但_有时_没关系”）。

没有帮手，我最终总是做这样的事情：

<select>
    <option value='ak' {{#if ak_selected}}selected{{/if}}>AK</option>
    <option value='al' {{#if al_selected}}selected{{/if}}>AL</option>
    <option value='ar' {{#if ar_selected}}selected{{/if}}>AR</option>
    <option value='az' {{#if az_selected}}selected{{/if}}>AZ</option>
    <option value='ca' {{#if ca_selected}}selected{{/if}}>CA</option>
    ....
</select>

将所有这些额外的属性添加到对象似乎有点愚蠢。

webgovernor - 看看这个： http :

它是启用此功能的助手。 它需要一个 javascript 表达式，它的计算就像 javascript 给定上下文一样。 享受。

谢谢 tniswong，这与我的帮手非常相似。 我已经解决了这个问题，我只是想强调 Handlebars“无逻辑”教条的虚伪。

没问题。 我就在你身边。 我喜欢车把，但如果没有这个帮手，它就毫无用处。

我将此助手作为拉取请求提交，但被拒绝。 所以我提交了另一个删除 if 块的拉取请求。 也被拒绝了。 /叹

哈哈哈。 Github 需要一个点赞按钮。

被拒绝了？ -_-

Handlebars 毫无逻辑的宗教的顽固真是令人难以置信。

566 和 #568

他提到他可能会将它添加到自述文件中，但我并没有屏住呼吸。

+1对此！ 啊！

FWIW， Swag 存储库提供了添加比较、排序和其他漂亮东西的帮助程序。 没有它，我不会在 Handlebars 中构建任何东西。

也就是说，我个人同意让 Handlebars 保持尽可能少的逻辑，因为它保持干净、可扩展和可维护。 如果你想要更多，为项目范围之外的东西贡献一个像 _Swag_ 这样的 repo。 如果这个项目的维护者改变主意，只需要一个拉取请求：+1：

@aboutaaron如果您要发表类似“让 Handlebars 保持尽可能少逻辑的声明，因为它可以保持清洁、可扩展和可维护”，您至少应该有礼貌：

1. 提供证明把手不包含逻辑的证据。 如果您已阅读该线程，那么您将看到它已经被证明包含if语句形式的不完整逻辑，该语句仅检查“真实性”，如果您还没有通读该线程，那么我会建议你这样做。
2. 以if语句的形式提供不完整逻辑的证据，该语句仅检查“真实性”，以某种方式“保持其清洁、可扩展和可维护”。
   这不是矛盾吗？ 如果handlebars 是可扩展的，这是否意味着提供条件语句的完整实现是微不足道的？
   例如，与使用handlebars AND swag的开发人员相比，提供完整的if语句的handlebars 如何使它更不干净、可扩展和可维护？
   有人可能会争辩说，使用swag助手会降低代码库的整洁度、可扩展性和可维护性，因为您需要为每个比较运算符使用不同的助手，即gt 、 gte 、 is 、 isnt 、 lt 、 lte以及每个逻辑运算符，即and 、 or 。
   与使用任何其他语言在if语句中执行所有这些操作相比，这如何使代码更具可读性？ 如果是这种情况，那么我会假设编程语言本身会取消检查“真实性”以外的任何内容的条件语句？ 我没有看到这种情况发生。

如果您碰巧要使用“将业务逻辑放入模板中”的陈词滥调 - 并且被证明是错误的，请不要。 这已经在这个线程中解决了 - 几次，由几个人 - 。 同时，如果您认为这是一个有效的论点，那么就不需要使用swag库，这与您之前的陈述相矛盾。

总而言之，事实上，有几个库试图为车把中if的不完整实现增加完整性 - 以一种或另一种方式 - 表明需要这种类型的功能核。 看一下 JavaScript 语言本身，Harmony 引入了很多第三方库、迭代器、模块、生成器、类、代理等已经提供的特性； 并且 DOM API 还实现了由第三方库提供的特性，querySelector[All]、CORS，甚至在 chrome canary 中实现了 DOM Promises。

没有证据表明“让 Handlebars 保持尽可能少逻辑，因为它保持清洁、可扩展和可维护”。 与此同时，其他人和我已经表明——在这个线程的先前评论中——一点点可以有很长的路要走，如果车把提供一个完整的if实现，它将为开发人员提供一个统一的 API 来制作他们的模板更易于阅读和维护。

@constantology +1 阿门。

在尝试了 {{#if something > something_else}} 并意识到这种情况的真相后，我才来到这里。 然而，我很想同意车把上的人。 我用了很长时间的液体，像这样的评论线程不可避免地会导致添加一些半生不熟的功能，比如真正属于后端的数学和字符串连接。

“无逻辑”if 语句的目标似乎是：在后端执行逻辑部分，并将“答案”作为单个变量呈现给把手。 如果答案是“是”，请执行此操作，否则执行其他操作。 我看不出有什么问题（阅读了上面的评论），我现在要去修复我的代码。

正在处理一些 Ember 应用程序，并想提出我的意见。 我觉得#if语句如果 _(可选)_ 接受一个参数会更好。 我完全理解离开logic-less的愿望，但有时与它一起工作会非常令人沮丧。

想象一个可以选择或取消选择的简单问题列表。 真的，这两个逻辑块之间有什么区别？

{{#if isSelected question}}
  <p>This question is selected</p>
{{else}}
  <p>This question is NOT selected</p>
{{/if}}

{{#if question.isSelected}}
  <p>This question is selected</p>
{{else}}
  <p>This question is NOT selected</p>
{{/if}}

在我需要如何编写支持这两个示例的代码方面存在相当大的差异。 这将是非常不错的，可以灵活地选择，要么。 我也没有真正看到第一个包含比第二个更多的逻辑。

我的感受与此线程所说的完全相同。 然后，我找到了这个线程。
因此，我想我刚刚了解了 Handlebars 的哲学。
然后，我想通了我需要的是像 Swag 这样的助手系列。

现在我没有问题，因为 Swag 会帮助我。
但是，我感到困惑，因为默认的if助手太简单了。
如果你说 Hanlebars 是无逻辑的，我怀疑 Handlebars 需要内置的助手。
如果它没有内置的助手，我想我可以更容易地理解 Handlebars 的哲学。

我可能对logic-less和business logic不太了解，我想告诉你我的想法。

我相信您根本不能将单个 if/unless（没有条件）视为逻辑，因为它只是 - 在无逻辑上下文中 - 一种表示布尔数据的方法，如“{{foo}}”语法是表示字符串数据的一种手段。

所以我认为应该停止以下行为：“如果它是无逻辑的，为什么会有 if 语句？HA-HA，将死！！！”

然后将其更改为“{{#exists}}”而不是“{{#if}}”，因为这更有意义。

在2013年10月5日，在上午10点52，cal127 [email protected]写道：

我相信您根本不能将单个 if/unless（没有条件）视为逻辑，因为它只是 - 在无逻辑上下文中 - 一种表示布尔数据的方法，如“{{foo}}”语法是表示字符串数据的一种手段。

所以我认为应该停止以下行为：“如果它是无逻辑的，为什么会有 if 语句？HA-HA，将死！！！”

—
直接回复此邮件或在 GitHub 上查看。

:thumbsup: 用于将 {{#if}} 更改为 {{#exists}} 或 {{#isTrue}}

我同意我们可以找到一个更合理的名字。 'exists' 会这样做，我的建议是“true”或“on”。

但尽管如此，由于历史原因，“如果”这个名字仍然更合适。 Handlebars 的 if 实现在语法上与任何其他 if 实现没有什么不同，它符合旧的“if ([predicate]) [do sth]”语法。

不同的是 [predicate] 必须是一个裸 bool 变量，它不能是一个表达式。 但这不是'if'的限制。 这是由于缺乏对 Handlebars 解释器表达式的支持而导致的更通用的限制。 （我认为这正是使 Handlebars 无逻辑的原因）

这意味着这个“如果”与任何其他“如果”没有什么不同。

并且尝试更改“如果”的名称可能会被某些人认为是异端邪说，不要说我没有警告您。

称它为{{#truthy}}和{{#falsey}}因为这就是{{#if}}和{{#unless}}所做的。

致开发人员：把你的脑袋从沙子里拿出来。 严重地。 你可以看到需要一个适当的 if 语句（我打算从字面上使用“需求”这个词）所以去实现它，而不是抱怨无逻辑。 如果您希望模板没有逻辑，请取消所有逻辑，包括{{#if}}和{{#each}} 。

只需实现一个适当的 if 语句。
强烈相信自己的无逻辑性的人应选择不使用它。 简单的。 作为。 那。

我什至已经为你完成了工作。

https://github.com/wycats/handlebars.js/pull/566
https://gist.github.com/tniswong/5910264

在2013年10月5日，下午3:20，thany [email protected]写道：

称它为 {{#truthy}} 和 {{#falsey}} 因为这就是 {{#if}} 和 {{#unless}} 所做的。

致开发人员：把你的脑袋从沙子里拿出来。 严重地。 你可以看到需要一个适当的 if 语句（我打算从字面上使用“需求”这个词）所以去实现它，而不是抱怨无逻辑。 如果您希望您的模板没有逻辑，请取消所有逻辑，包括 {{#if}} 和 {{#each}}。

只需实现一个适当的 if 语句。 强烈相信自己的无逻辑性的人应选择不使用它。 简单的。 作为。 那。

—
直接回复此邮件或在 GitHub 上查看。

谢谢你，但解决方案应该在核心包中。 “ifTest”这个词大概只是因为 Handlebars 在你可以使用它之前劫持了“if”这个词。

另一件事是，您的 ifTest 接受一个字符串，并在运行时对该字符串进行评估，而如果核心包中包含正确的 if 块，则它可能位于已编译的模板中（这正是 Handlebars 的强大功能之一）点 - 我不喜欢通过使用eval()来处理 ifs 和 elses 的点）

你是 100% 正确的。 只是使用我当时可用的工具。

无论如何，它有效。

在2013年10月5日，在下午03:41，thany [email protected]写道：

谢谢你，但解决方案应该在核心包中。 此外，术语“ifTest”大概只是因为 Handlebars 在您可以使用它之前劫持了术语“if”。 另一件事是，您的 ifTest 接受一个字符串，并在运行时对该字符串进行评估，而如果核心包中包含正确的 if 块，则它可能位于已编译的模板中（这正是 Handlebars 的强大功能之一）点 - 我不喜欢通过使用 eval() 来处理 ifs 和 elses 的点）

—
直接回复此邮件或在 GitHub 上查看。

在 Handlebars 中搜索比较时偶然发现了这个线程。 我认为您应该删除/重命名{{#if}}和{{#each}}块，或者实施适当的 if 语句。 它是每种语言的基本功能。 时期。 如果您真的想要无逻辑模板，为什么不直接使用 Mustache 呢？

我知道开发人员之间存在一种观点，即非开发人员（即设计人员）应该可以阅读模板。 但是 A) 我从来没有和设计师一起工作过这是一个问题，B) 我认为方法应该是一个通用的内置解决方案，作为扩展，你可以使用仅布尔值的检查，所以你有一个选择。 此外，添加诸如{{#ifValueEqualsA}}和{{#ifValueEqualsB}}将迫使您创建大量根本不需要的样板代码。 我在一个不太大的移动项目中工作，我已经有 200 行代码，它们只是为特定需求添加比较。 这违背（希望）每个开发人员的思维方式，即事物应该尽可能通用。

@cal127 “我相信您根本无法将单个 if/unless（无条件）视为逻辑”-那么问题是什么？ 为什么检查表达式比检查布尔值更符合逻辑？ 是支票。 时期。 这是这里完成的逻辑，而不是表达式（因为布尔值是 - 猜猜是什么 - 表达式）。 当然，假设表达式代表的不是业务-，而是UI逻辑。

很抱歉，无逻辑模板引擎的想法似乎已经奄奄一息……我认为未来不会再发生这种情况。 开发人员需要能够让事情变得更简单、更快速而不是更复杂的工具。

@thany岩石。 昨天我谈到了 mustache（另一个无逻辑的模板语言），这正是几分钟后我脑海中出现的问题。 程序员怎么会认为这很酷。 这只会让事情变得更糟。 我知道的编程范式是“业务逻辑与演示逻辑的分离”。 这 def 意味着表示中有逻辑（例如，包含/包含模式中的模板的视图，例如 mvc）。 他们怎么会试图否定这一点并从演示中删除逻辑。

场景：我在视图中运行一个循环，我想在 x 次迭代后执行一个操作。 有了车把，我现在必须创建一个助手，然后在循环中使用，对吗？ 这如何让我的生活更轻松？ 如果 count==x 会发生什么？？？？ 这比使用像 php 这样的语言来做模板更好吗？ 它如何帮助设计逻辑模板引擎？

我？ 对于面向逻辑的工作来说，没有逻辑的东西。 对不起！

我无法相信你是多么无知，亲爱的无逻辑信徒。 这只是不现实，它是一个完整的神话，一个谬论，一个错误的宗教。 没有超过几行的模板是完全没有逻辑的。 这根本不实用。

现在，将这种信念强加给您的用户完全是您的决定。 但是一直不理会任何对逻辑的要求是愚蠢和无知的证明。 特别是在这种特殊情况下，因为已经有大量的逻辑可能，尽管微乎其微。

我再次强烈敦促您重新考虑。 不，等等，不要再考虑了。 只要倾听并做正确的事情。 不希望在他们的模板中有任何愚蠢逻辑的人可以继续他们的邪恶方式并跳过各种箍，以免使用逻辑。

扩展 if 块以进行适当的比较并不会取消其当前用途。 它不会给那些还没有看到逻辑之光的人制造麻烦，那些人可能会继续像他们一样编码。

这不是关于酷； 您自己使用逻辑与演示的分离作为论证，然后忽略它以要求简化您的生活。 您可以将任何标准车把模板库添加到您的项目中或编写您自己的。

您或其他任何人都没有在众多线程中的任何一个中解决过反对这一点的众多论点中的任何一个。 只是为了使这些论点在此线程中清晰可见：
1) 你将破坏现有的生态系统； 对于想要更新但拥有自己的 IF 大约 2 年的团队来说，这将导致冲突和返工。
2) 如果您需要，现有的帮助程序库将添加，以及您接下来需要的所有其他帮助程序。
3）一旦同意添加这个'if'，新的论点将是它的实现。 姓名。 句法。 参数。 如果出现这种情况，您可能会承诺会感到满意，但其他人不会。 马上会有一个新线程在这里争论它应该以其他方式工作。
4) 现有的“if”正是 -rendering- 应该存在的。 “如果存在 Y，则显示 X”。 这与业务逻辑无关； 这应该发生在你的模型中（我建议 Backbone，然后你可以拥有你想要的任何东西，只是在你的模型上是一个 isXXX() 方法）。

由于我们正在互相询问事情，如果您没有很好的技术论证来进行重大更改，请不要继续这样做。 感到沮丧是愚蠢的 - 添加您想要的“如果”并完成。

1）不，你不会。 如果你什么都不做，模板应该保持工作。 当然，一切都应该向后兼容。 即使不是，也不要升级。
2) if 语句是基本的。 你所说的就像汽车上的轮子现在是可选的。
3) if 语句的语法并不重要。 每一种编程语言都有一种，而且每一种都做完全相同的事情。 所以选一个就好了。 更重要的是，拥有任何适当的 if 语句都比我们现在拥有的要好。
4）错，向上搜索“模板逻辑”。

至于你最后的立场，论据_已经_提出，而且是合理的。 它一次又一次地被争论，但它确实看起来像一种宗教。 坚不可摧，却又如此脆弱。

乔治·弗里克——

1) 这与升级曾经存在的任何其他框架或库有什么不同？
2）你说得对。 但是，对于如此基本和必要的东西，手动添加这些基本功能不应该是必要的。
3）这就是拉取请求的用途。
4）你完全没有抓住重点。 该线程上没有人在视图层中争论业务逻辑。 我们正在争论在视图层中使用有用的显示逻辑。 给出的“if”不是一个真正的 if，这让任何曾经使用过编程语言的人都感到困惑。 它更像是一种“存在”。

如果您认为添加它会导致人们在模板中使用业务逻辑，那么您可能是对的，因为您无法解决愚蠢的问题。 仅仅因为有人可以做坏事并不意味着你应该阻止其他人在这个过程中做一些好事（和必要的）。

在2013年11月22日，在3:55 PM，乔治·弗里克[email protected]写道：

这不是关于酷； 您自己使用逻辑与演示的分离作为论证，然后忽略它以要求简化您的生活。 您可以将任何标准车把模板库添加到您的项目中或编写您自己的。

您或其他任何人都没有在众多线程中的任何一个中解决过反对这一点的众多论点中的任何一个。 就这样，这个线程中的论点很清楚：
1) 你将破坏现有的生态系统； 对于想要更新但拥有自己的 IF 大约 2 年的团队来说，这将导致冲突和返工。
2) 如果您需要，现有的帮助程序库将添加，以及您接下来需要的所有其他帮助程序。
3）一旦同意添加这个'if'，新的论点将是它的实现。 姓名。 句法。 参数。 如果出现这种情况，您可能会承诺会感到满意，但其他人不会。 马上会有一个新线程在这里争论它应该以其他方式工作。
4) 现有的“if”正是 -rendering- 应该存在的。 “如果存在 Y，则显示 X”。 这与业务逻辑无关； 这应该发生在你的模型中（我建议 Backbone，然后你可以拥有你想要的任何东西，只是在你的模型上是一个 isXXX() 方法）。

由于我们正在互相询问事情，如果您没有很好的技术论证来进行重大更改，请不要继续这样做。 感到沮丧是愚蠢的 - 添加您想要的“如果”并完成。

—
直接回复此邮件或在 GitHub 上查看。

@thany
反驳一个论点和驳回它是有区别的。 “错误”等同于“NUH UH！”。
尽量不要太私人化。

@tniswong
1) 不是，这在任何框架中都适用。
2）如果你在一般意义上应用这个，Node 应该包括它的所有组件。 它们是基本的或必要的可以争论，但会导致在标准框架之外将它们组合在一起是很好的抽象和分离的想法。 许多项目只是不需要它们中的任何一个，而其他项目则需要特殊版本。 所以你可以插入一个标准集，编写你自己的，或者不使用。 默认情况下，所有这些助手都没有（再次）任何技术上合理的理由。
3）你的陈述并没有以任何方式否定原来的观点，事实上 - 你帮助它。 20 个拉取请求来修复 If。 我敢打赌开发团队会喜欢通过它们。
4) 没错，它是一个“存在”。 如果存在，则渲染它。
当你不能写“任何人”时，它需要一个反例。 _举手_。

根据上述说明，在我看来，以下其中一项是必要的：

1. 将if重命名exists并停止调用把手“无逻辑”（因为它不是）
2. 添加对if支持以作为if语句。
3. 完全删除if 。

我对这些选项中的任何一个都感到满意。

不要忘记{{#unless}}

2013 年 11 月 22 日下午 4:40，Aaron M [email protected]写道：

根据上述说明，在我看来，以下其中一项是必要的：

重命名是否存在并停止调用把手“无逻辑”（因为它不是）
添加对 if 的支持以作为 if 语句。
如果完全删除。
我对这些选项中的任何一个都感到满意。

—
直接回复此邮件或在 GitHub 上查看。

我认为这真正归结为 Aaron 很好地总结了这一点。

1. 有一种虚伪需要通过声称没有逻辑并提供 if/unless 来解决。
2. 给定的“如果”用词不当。

修复它们，这个论点就消失了。

2013 年 11 月 22 日下午 4:43，Todd Niswonger [email protected]写道：

不要忘记{{#unless}}

2013 年 11 月 22 日下午 4:40，Aaron M [email protected]写道：

根据上述说明，在我看来，以下其中一项是必要的：

重命名是否存在并停止调用把手“无逻辑”（因为它不是）
添加对 if 的支持以作为 if 语句。
如果完全删除。
我对这些选项中的任何一个都感到满意。

—
直接回复此邮件或在 GitHub 上查看。

@乔治弗里克
我之所以驳回他的论点，只是因为它之前已经被驳斥了一百万次。 我们已经解决这个问题太久了，它必须结束。 一定要加if语句，谁都不会吃亏，大家都开心。 不想要它就像不想要所有房子里的空调一样。 我会判断我想要什么在我的房子里。 如果它在你的手中而你不想要它，那么就让它吧。 就那么简单。

@webgovernor
无需重命名。 一个适当的 if 语句可以与当前的完全兼容。 目前它只是“if boolean then...”，并且任何功能齐全的if语句都可以做到这一点，只有那个布尔值现在可以是任何表达式而不仅仅是一个变量。

@tniswong
他们有多好，对吧？ 添加一个肮脏的额外标签，因为他们实现的 if 块过于简单，甚至无法否定表达式。 但是在未来的 Handlebars 中，除非标签可能只是成为“if not”的别名。 有点像编程中的 do..while 与 while..do，两者的存在主要是为了可读性，而不是_真的_出于任何技术原因。

我也希望在 Handlebars 中进行基本比较。 我理解无逻辑的哲学。 我也相信基本的比较支持会更直观，并允许用户更有效地工作。 如果大量用户将基本的比较逻辑转移到助手上，那么这种理念不会帮助他们或劝阻他们感知到的次优行为——它只是在创造更多的工作。

@jeremiahlee不确定您是否同意或不同意我的观点，我可以通过任何一种方式阅读您的评论:)

无论哪种方式，我过去都曾与 Handlebars 合作过，并且我已要求他们实施适当的 if 块。 这导致了大量关于逻辑应该保留在模型中的虚假哲学的评论。 没有 Handlebars 开发人员希望在他们自己的小世界之外思考这么多（这是一个粗鲁的词，但我会跳过它）。 只要看看这个线程作为证据。

这迫使我编写了一个名为“when”的助手来进行比较。 仍然没有适当的 if 块构造，但当时对我来说已经足够接近了。 不过，它确实为我创造了很多不必要的工作。

@thany ：我同意 Handlebars 应该对内置的两个值进行基本比较。无逻辑模板也不应该是无同理心的。

我也会投票给@thany和其他论点。 if else语句太基本了。
条件类和带有预选option的select框应该可以使用默认的车把包。

使用嵌套的助手，这不再是一个问题，例如

{{#if (greater-than array.length 3)}}
  ...
{{/if}}

很好的例子@mmun :+1:

有点奇怪，我没有看到任何布尔组合器......但最重要的是，它并没有改变这个项目维护者的整体立场，这似乎是一个牢不可破的“没有逻辑！！11！！ 1!1" 那种观点。