1

在“简单”网站上这是更好的做法。（很少有 JavaScript 动作）

a：将事件/动作/函数附加到元素上（div/span/...）

就像如何将此按钮和单击事件添加到某些 div：

$( "#create-user" )
  .button()
  .click(function() {
  $( "#dialog-form" ).dialog( "open" );
  });

b：或在线让元素动作调用函数。

<div id=calc onclick="doCalcFunc(this)">calc something</div>

这是来自更多来自 OO 背景的人的质疑，java/c#，所以发现更喜欢 B，很容易找到正在发生的事情。也许它只是在学习更多关于 web 调试工具的知识，但是能够在一个元素上点击 go to source，然后看到，哦，当你点击这个元素时，它会运行函数 X。至于方法“A”，我必须在源上搜索可能附加到元素 ID、类型、类或元素的其他指示符的某些函数。

4

2 回答 2

4

即使对于一个简单的网站，选项 A中显示的格式也会更好，因为它将代码与 HTML 标记分开。这也是Unobtrusive JavaScript的主要原则之一。

根据我的经验，使用 HTML DOM 或 JQuery 等框架替换和修改附加到元素的事件要容易得多，然后是替换标记中的多行内联代码。我工作的大多数网站都有动态生成的内容，使用内联函数维护所有这些代码会很痛苦。

此外，选项 A（将事件附加到元素上）还允许您使用各种函数，例如匿名函数和各种样式的闭包。在选项 B 中，doCalcFunc需要在div元素之前定义才能起作用。使用选项 A，可以在函数附加到 div 的事件时定义函数。这允许在初始编码和将来维护站点时有更大的灵活性。

于 2013-04-22T14:09:44.687 回答
1

虽然我大部分时间会使用基于 JS 的处理程序分配，但有时处理程序属性可以很好地工作。

重要的是不要丢弃任何潜在的工具，而是要了解这两种技术的优缺点，我将在下面尝试列出。我将尝试给每个“骗局”一个对位以供考虑。

元素属性处理程序

优点

  • 处理程序在节点创建后立即可用（零延迟）。
  • 赋值非常简单，并且具有极其广泛的跨平台支持。
  • 提供一个不与 CSS 重叠的元素的钩子（使用样式和行为的类）
  • 附加到元素的行为的标记中的即时可见性。

缺点

  • 混合行为和表现。
    • Counter：虽然确实如此，但这只是在嵌入大量 JavaScript 时才会出现的问题。单个函数调用并不比给元素添加一个类更显眼。
  • 代码eval在每个事件上都有。
    • 计数器：这个实际上不是真的，但它通常被认为是一个骗局，我想我会把它包括在内。事实是，它只eval在页面加载时执行一次，就像 JavaScript 的其余部分一样。
  • 如果有多个元素具有相同的处理程序，您不会共享一个函数，而是每个元素都有一个唯一的函数。
    • 计数器：这是真的。即使函数调用相同，也会为每个元素、每个事件创建一个新函数。但是如果有几个共享同一个处理程序，则可以为事件委托提出一个案例。
  • 高维护。对函数的更改意味着必须更改标记以匹配。
    • 计数器：这是真的，尽管在 JavaScript 代码中添加处理程序可能会在类名更改或标记更改破坏 DOM 选择时遇到类似的问题。
  • 每个元素、每个事件类型只能分配一个处理程序。
    • Counter：这是真的，尽管您可以拥有一个调用其他函数的通用函数，这有点类似于 jQuery 在后台的工作方式。
  • 可能与 JavaScript 中分配的处理程序发生冲突。分配onclick="foo()"属性时，您实际上是在将函数分配给element.onclick. 由于每个元素只能分配一个，因此对 JS 中属性的任何更改都会覆盖您的处理程序。
    • 计数器：这是真的。虽然这绝对需要考虑，但不应将其用作.onclick完全取消内联或处理程序的理由。有很多情况不会发生冲突。

在 JavaScript 代码中分配的 jQuery 处理程序

优点

  • jQuery 使它非常简单和兼容。
  • 没有将 JavaScript 与标记直接混合。
  • 对处理程序的更改完全在 JavaScript 中完成，当涉及多个元素时不太可能需要重复更改。
  • 内置浏览器兼容性修复程序。

缺点

  • 如果处理程序是在 DOM 准备就绪后分配的，则可能有一段时间元素在没有 JavaScript 行为的情况下可见。
    • 计数器：虽然是这样，但这通常不是问题。如果您通过慢速连接发送大页面，这可能是最相关的。在这些情况下，您可以将脚本嵌入到更靠近元素的位置，而不是等待整个 DOM。
  • 需要一个过于复杂的 DOM 就绪解决方案。
    • 计数器：不是真的。虽然有些人选择使用此类解决方案，但没有理由不能将分配处理程序的脚本简单地放在页面底部。
  • 当向一个元素添加第一个处理程序时，jQuery 实际上创建了另一个函数，即使实际的处理程序在多个元素之间共享。
    • Counter：虽然这是真的，但它仅适用于分配给元素的第一个处理程序。分配的其他处理程序可以共享 jQuery 制作的“幕后”处理程序，因此额外开销仅在第一个处理程序上，每个元素。
  • 有其自己的“突兀”问题，其中类可能被 JavaScript 和 CSS 团队使用，允许其中一个或另一个通过更改类来破坏代码。
    • Counter：虽然是这样，但在这种情况下，多个类可以与命名约定一起使用，从而为每个团队提供不干涉指标。
  • 从标记中看不到该行为。
    • 计数器：如果类专门用于处理程序分配，并且使用了良好的命名约定，那么它们可以与内联处理程序一样具有描述性。
  • 为 JavaScript 添加一个类并不比添加一个内联处理程序更引人注目。
    • Counter：虽然doing 与doingclass="click_handler"确实没有太大区别onclick="handler(this)"，但如果使用设计良好的DOM，您很可能完全不需要类就可以完成您的作业。（尽管您会失去标记中的可见性优势。）

因此，在努力避免对任何一种方法的任何形式的宗教信仰的同时，我试图提供一些关于两种方式的一些考虑的概述。

虽然您可能会发现自己大部分时间都在使用更流行的 DOM-ready 方法来分配处理程序，但在某些情况下，内联处理程序可以很好地满足要求，尤其是在零延迟方面很重要的情况下。

于 2013-04-22T15:43:06.067 回答