Angular.js: 我如何删除由 ng-if 和 ng-repeat 创建的评论？

创建于 2014-08-22 · 40评论 · 资料来源: angular/angular.js

有没有办法阻止 Angular 创建“助手”HTML 注释？例如，

<div ng-include="myTemplate"></div>
会变成类似的东西

<!-- ngInclude: 'hurr-durr.html' -->
<div ng-include="myTemplate"></div>

我该如何阻止？

$compile won't fix inconvenient

资料来源

cc17

👍13

最有用的评论

评论会显示一些我不想要其他人的产品逻辑
看。

2014-08-26 7:05 GMT+08:00 布赖恩福特通知@github.com ：

@cc17 https://github.com/cc17为什么要去掉这些
元素？可能有更好的方法来实现您的目标。
—
直接回复此邮件或在 GitHub 上查看
https://github.com/angular/angular.js/issues/8722#issuecomment -53349716。

cc17 于 2014-08-26

👍14

所有40条评论

我不能告诉你它在内部是如何工作的，但是 angular 需要这些注释来跟踪可能有也可能没有实际 DOM 节点作为输出的指令。例如，当 ngIf 为 false 时，没有 DOM 节点，但是 angular 编译器需要注释来知道指令位于树中的哪个位置。我相信其他人，例如@caitp可以更好地解释这一点。

Narretz 于 2014-08-22

@cc17为什么要去掉这些元素？可能有更好的方法来实现您的目标。

btford 于 2014-08-26

👎2 👍1

评论会显示一些我不想要其他人的产品逻辑
看。

2014-08-26 7:05 GMT+08:00 布赖恩福特通知@github.com ：

@cc17 https://github.com/cc17为什么要去掉这些
元素？可能有更好的方法来实现您的目标。
—
直接回复此邮件或在 GitHub 上查看
https://github.com/angular/angular.js/issues/8722#issuecomment -53349716。

cc17 于 2014-08-26

👍14

我同意@cc17。甚至我也想达到同样的目标。

ghost 于 2014-08-26

@cc17我想了解这一点。由于本主题之外的原因，Angular 需要存在这些注释节点。
现在，你说

评论会显示一些我不希望其他人看到的产品逻辑

你是说那个

您希望评论节点不显示任何信息吗？即如果这些是空的评论节点，那就没问题了
评论节点根本不应该在那里

如果您在谈论第一个选项，那么我认为这可能有点牵强，但有可能添加一个选择加入。如果您在谈论第二个选项，那么删除它们将涉及对指令嵌入如何工作的重大重构，我怀疑这会很快发生。

lgalfaso 于 2014-08-29

@lgalfaso

您希望评论节点不显示任何信息吗？即如果这些是空的评论节点，那就没问题了

我可以说这将是一个选择。

DigitalSmile 于 2014-09-12

@lgalfaso是的第一选择很好。公开不会破坏当前指令行为的基本评论体。

ghost 于 2014-09-15

我来到这里寻找相同问题的相同答案，但出于不同的原因（调试具有一百万条评论的 DOM 元素真的很烦人）。

听其他人描述 Angular 对评论的依赖，这是有道理的。为您对隐藏应用程序逻辑的担忧加上我的两分钱.. Angular 是 javascript，我们都知道，没有办法真正保护您的 javascript 代码免受真正想要达到峰值并查看您在引擎盖下得到什么的用户的保护。在我看来，删除评论只会让不经意的人看不到你的逻辑。它不会阻止攻击者，如果攻击者甚至将您的角度注释视为查找代码中可能暴露或弱点的途径，我会感到非常惊讶。

seavor 于 2014-12-27

👍7

@cc17
“评论会显示一些我不想让其他人看到的产品逻辑。”
? 要查看评论，您必须打开浏览器的开发工具。
在那里，显示了您的所有（前端部分）产品逻辑！您的 html（原始和当前）、javascript、网络请求...

frfancha 于 2015-01-10

@seavor
“调试带有一百万条评论的 DOM 元素真的很烦人”
我想知道您可以创建哪个角度页面（具有可接受的响应时间；-)）生成“一百万条评论”

frfancha 于 2015-01-10

👍1

我也希望看到一个从实时 HTML 中删除评论的选项。在我看来，它既丑陋又令人分心。与我的文本编辑器不同，开发者控制台占页面的 1/3，因此这些额外的注释确实是错误的。

是否有更多细节说明为什么 Angular 需要这些？

F1LT3R 于 2016-02-10

👍5

丑陋和分散注意力并不是一个非常有力的理由。 😉
Angular 将注释用作将要显示的内容的标记
插入那里。例如，未显示的 ngIf 元素需要这个。
所以我认为他们永远不可能成为现实
移除。 Angular 2 理论上应该有同样的问题，但也许是
那里不同。
是2016年2月10日19:16 schrieb“阿利斯泰尔ģ麦克唐纳” < [email protected]

：
+1
我也希望看到从实时 HTML 中删除评论的选项。
在我看来，它既丑陋又令人分心。
是否有更多细节说明为什么 Angular 需要这些？
—
直接回复此邮件或在 GitHub 上查看
https://github.com/angular/angular.js/issues/8722#issuecomment -182509708
.

Narretz 于 2016-02-10

是的，ng2 也有对结构指令的评论。（我认为他们使用了<script>元素，但在某些时候切换到注释，因为这些元素破坏了 CSS 选择器 iirc。）

gkalpak 于 2016-02-10

是的，理解@Narretz ，丑陋可能不是很大的动力，但目前尚不清楚实际的权衡是/是什么。使用现有的 DOM 节点是否性能更好？我无法想象这会产生很大的不同（也许我离那个很远）。或者只是遍历 DOM 节点而不是创建 JavaScript 数组更容易？

F1LT3R 于 2016-02-10

@F1LT3R ，注释节点作为标记存在。当内容未显示时，它们是必需的（例如， ngIf表达式评估为假， ngSwitchWhen值与当前ngSwitch表达式不匹配等）。在这种情况下，我们需要在 DOM 中使用占位符来知道稍后将实际元素插入到何处（例如，当ngIf表达式的计算结果为 true 等时）。

gkalpak 于 2016-02-10

我希望会有一个选项。

留下这样的评论，我认为这不是一个好主意


teknosains 于 2016-02-16

👍6

@codetrash ，如果你有更好的提议，我们

gkalpak 于 2016-02-16

@codetrash为什么这不是一个好主意？

Narretz 于 2016-02-16

@Narrez用于非常敏感的应用程序，如银行、支付服务等......离开这个

!-- ngIf: transaction.status==9 && transaction.status!==8 -->

可能会导致危险的情况。

@gkalpak可能会留下加密标记等。你有吗？

teknosains 于 2016-02-16

👍1

@codetrash表达式标记基于您的 javascript 代码，该代码无论如何都会暴露给用户代理。混淆您的 Javascript 代码可能会使获取信息变得更加困难，但您的应用程序逻辑仍然可以被提取。我们当然可以尝试删除/混淆表达式，但我个人认为这里没有安全风险并且它的优先级很低。如果有人想试一试，非常欢迎你，虽然我不能保证它会被合并。

Narretz 于 2016-02-16

👍1

谢谢@gkalpak ，有道理。我可以理解为什么尝试跟踪 JS 中的 DOM 更改对于性能和可维护性来说可能非常不切实际。我想如果我们可以说“Angular 控制 DOM 中的所有东西”它可能更可行一些，但 Angular 往往会与各种 3rd-party 库混在一起，所以......呃。 “两害相权取其轻”。

F1LT3R 于 2016-02-16

@codetrash
<可能会导致危险的情况>>
?? 无论如何，您可以在第一阶段以明文形式发送的 html 中阅读此代码，所以......

frfancha 于 2016-02-16

+1。

smurugavel 于 2016-02-19

@smurugavel请不要简单地 +1 这个问题。仍然没有令人信服的理由反对这些评论，所以简单的 +1 不会让我们实现这一点。

Narretz 于 2016-02-20

@Narrez ，就像@cc17所说的，业务逻辑是我所关心的，其他可以通过开发人员工具查看源代码的人不需要看到业务逻辑。
通过此线程中的建议， @lgalfaso的第一个选项对我来说是可以的。
或者，angular 团队是否可以加密这些人类无法阅读的评论或添加一个 angular 可以在内部跟踪的唯一标识符？只是我的想法..

smurugavel 于 2016-02-23

@smurugavel ，正如本主题中已经提到的，这些评论不包含在模板中作为纯文本不可见的任何内容。谁能看到你的源代码，谁就能看到这个业务逻辑。去掉评论并不能解决你的问题。

gkalpak 于 2016-02-23

我希望有一个选项可以删除并在过滤时再次获得它。

留下这样的评论，我认为这不是一个好主意

如果此时我必须应用过滤器并再次使用 ul li，我的评论 li 值会再次出现在视图中，还有什么办法呢？

ManishLSN 于 2016-02-24

@ManishLSN ，不确定你的意思。没有评论li 。只是一个普通的 HTML 注释。
也就是说，我相信当debug info被禁用时有空注释是有意义的（注释的内容除了“可调试性”之外没有任何其他目的）。

WDYT @Narretz ， @lgalfaso ？

_{再次（对于提出这个问题的人），这将会对安全没有影响。}

gkalpak 于 2016-02-24

我们需要将注释节点放在 DOM 中，否则 Angular 根本行不通。
如果 debugInfo 被禁用，我们可以实现删除注释文本的想法。这是一个相当直接的变化。 PR有人吗？

petebacondarwin 于 2016-02-24

谢谢！！！

smurugavel 于 2016-02-25

@codetrash这是关闭的，我认为它有利于“隐藏”检查员的逻辑。但如前所述，您的纯 HTML 和 JS 提供给浏览器，因此不应以任何方式认为它更安全。通过使用带有 2.0.0 的服务器端 angular，这可能会得到更好的保护。在任何情况下，我能看到的唯一“危险情况”是他们是否可以更改检查器中的值，并查看或保存他们不应该执行的数据 - 但这可以通过不向模型提供该数据来停止第一名。如果应该对用户隐藏敏感数据，那么从服务器发送敏感数据应该被认为是不好的做法 - 换句话说，应该在服务器端强制执行权限，特别是对于银行、支付服务等。发送到浏览器的任何内容都应该是被认为是公开可用的。

jdforsythe 于 2016-02-27

👍2

这是一个有趣的用例 Akuno。我可以设定为什么会这样
令人沮丧。

我认为在实践中你会想要过滤掉某些元素，即使在
非 Angular 场景。我框架，评论等。

有更多的工作要实施，是的，但更清洁更可控的管道
在一种格式和另一种格式之间可能是一个好主意。
2016 年 3 月 25 日凌晨 2:55，“akunno”通知@github.com 写道：

我希望我能正确理解这一点，因为我在一条类似的船上。
目前我的 dom 包含很多这样的评论和图像：
当我在元素的父元素上调用 innerHTML 时，我最终得到了一些东西
像这样：
ng-src="data:image/gif;base64,....">
我不知道在没有角度指令的情况下提取 HTML 的方法。
我正在尝试提取没有角度的渲染 HTML，因为我正在传递
这到一个转换器，它从中创建一个 word doc。目前这个词
doc 包含一堆带有红色 X 的图像标签，因为它仍在尝试
将图像渲染为图像。评论也是海量
增加字符串的大小。
我试图删除评论，但我仍然想不出办法
在没有角度指令污染它的情况下提取呈现的 HTML。
理想情况下，当我调用 innerHTML 时，我想看到如果
如果 ngIf 返回 false，则 ngIf 为 true 或什么都没有。
我希望我能正确理解这一点，这是一种 +1
以某种方式提取没有注释/指令的渲染输出。
—
你收到这个是因为你被提到了。
直接回复此邮件或在 GitHub 上查看
https://github.com/angular/angular.js/issues/8722#issuecomment -201172995