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-ish中移动方向无论如何（例如使用component指令）。做好准备...

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

1 个答案: