为什么将 AngularJS 指令限制为类是不好的？

Question

我们一直在避免将 Angularjs 指令限制为类。主要是因为我们发现了一些反对它的消息来源（包括John Papas opinionated styleguide）。同时，我们一直避免将其限制为元素，因为它会与 W3C 标准相冲突。 （我们就是这样的纯粹主义者）。

所以，我们一直在使用的只是限制属性（不，我们不会谈论评论方法）。在大多数情况下工作正常，但在部署具体对象时似乎太松了。例如。侧边栏。这以及replace: true 选项将是deprecated，让我想知道为什么不使用限制类。似乎有道理：

<nav class="maarten-sidebar">
    <!-- sidebar directive content -->
</nav>

对比：

<div data-maarten-sidebar>
    <!-- sidebar directive content -->
    <nav class="sidebar"></nav>
</div>

它也可以很好地与我们的 CSS 文件搭配使用。通过一些研究，我们发现有些人反对它。但主要原因不是很清楚。所以我的问题实际上是：使用restrict: 'C'的陷阱是什么

Answer 1

restrict: 'E' 通常被认为是带有模板的指令的最佳实践有几个原因（在 Angular 2 中称为 'components'，并受到 Angular 1 中新的 component 指令的鼓励）。原因实际上只是关于可读性和一致性，但我认为它们仍然令人信服。

主要原因正是因为它与 W3C 标准相冲突。根据标准，elements may not contain separate words delimited by a dash。 AngularJS encourages developers 在指令名称的某处使用破折号。因此，当您看到一个带有破折号的元素时，您会立即知道它是一个 Angular 指令，而不是标准的 HTML 元素。因此，使用restrict: 'E' 最终会更具可读性和表达性。

现在，对于没有模板的指令（Angular 2 中的普通旧 'directives'），通常首选 restrict: 'A'。大多数 HTML 属性不包含破折号，尽管有 nothing in the W3C standard 表示它们不能。主要原因似乎是它们赋予元素一种行为，而不是像许多 HTML 属性（例如onclick）那样简单地应用视觉样式。此外，如果指令接受输入，您可能会通过自定义属性绑定输入，如下所示：<nav expandable-nav expanded="false"></nav>。另一方面，这似乎很令人困惑：<nav class="expandable-nav" expanded="false"></nav>。

最后，也许顺其自然的主要原因是它们在 Angular 2 中被强制执行。不可避免地，Angular 2 将成为下一件大事，而 Angular 1 一直在向更 Angular-2 的方向发展无论如何方向（例如使用component 指令）。做好准备……