javascript - 为什么将 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 )。此外，如果指令接受输入，您可能会通过自定义属性绑定(bind)输入，如下所示:<nav expandable-nav expanded="false"></nav> 。另一方面，这似乎很令人困惑: <nav class="expandable-nav" expanded="false"></nav> .

最后，也许顺应潮流的主要原因是它们在 Angular 2 中得到了强制执行。不可避免的是，Angular 2 将成为下一个大事件，而 Angular 1 一直在朝着更加 Angular-2 的方向发展。无论如何方向(例如使用 component 指令)。做好准备...