jquery - 为什么 JQuery 不公开其 UUID 功能？

Question

在底层，JQuery 使用“UUID”映射(只是它维护为 jQuery.uuid 的计数器)来解决当您将属性附加到浏览器时浏览器存在的众所周知的内存泄漏问题。来自 Javascript 的 DOM 中的标签。相反，JQuery 使用 $.data(tag, name, value) 将数据存储在以 uuid 为键的映射中(可以通过检查 tag 来确定键) [jQuery.expando])。

虽然 $.data() 非常有用，但有时您希望将数据映射到标签，而不将该数据转储到一个全局存储桶中 - 您想要自己的较小的数据存储桶，您可以，例如，检查或循环的长度。

作为一个人为的示例，假设您的图标在单击时会在 4 种状态之一之间旋转。当一个处于状态 2 时，您希望将其添加到处于状态 2 的图标数组中。最明显的方法是将标签添加到数组中；但是这样做会造成内存泄漏。您可以在复选框上调用 $.data() ，但这并不能完全完成您想要做的事情 - 您必须循环遍历所有检查 $ 的复选框。 data() 针对它们来找出哪些在列表中，哪些不在列表中。

您需要在数组中存储标签的一些抽象，这就是 jQuery 的 UUID。您可以编写自己的 UUID 功能，但出于代码大小和质量原因，理想情况下您只需利用 JQuery 中内置的 UUID 功能即可。您可以通过调用 $.data(tag, 'irrelevant', 1) 要求 JQuery 将 UUID 隐式附加到标记，然后检查 tag[jQuery.expando] 以获取它的 UUID，最后在列表中使用它......但这有点麻烦。实际上，理想的做法是在公共(public) API 中公开以下内容:

$.getUuid(tag):检查并创建 UUID(如果不存在) - 理想情况下，该方法是从 $.data() 中提取出来的，并创建或获取传入的标签的 uuid。

那么，是否有原因没有将其分解到 jQuery 中自己的方法中？这在某种程度上有害吗？难道它从来都没有什么用处吗？

我应该注意到，我实际上已经在我们使用的 jQuery 版本中将其分解出来，并且它非常有帮助。但也许在我的使用中存在一个我没有遇到的潜在风险。我也知道有一个插件可以实现这一点，但它有点损坏 - 并且有 2 个代码路径来执行相同的 UUID 功能既有点浪费又有点脆弱。

Answer 1

我认为这里明显的答案是 jQuery 构建了他们的 uuid 供内部使用，并且没有看到一个很好的理由或很大的需求来费心让它公开使用。这并不意味着不存在原因，只是它们似乎还不够重要，不足以使其成为需要处理的事情的首要任务。

用作唯一 ID 的单调递增计数器实现起来非常简单，我已经使用过很多次了。我不觉得我需要类库支持才能做到这一点。

我认为你对内存泄漏的恐惧是因为你保留了对象引用，这有点过分了。首先，如果您删除该对象并忘记删除对其的某些引用，那么这只是内存泄漏。这只是垃圾收集语言中的一般规则，您必须“知道”在哪里保存对可以删除的对象的引用，并在您打算释放对象时清理这些引用。

其次，只有当您在每个页面上多次执行相同的操作或者对象非常非常大时，才会发生有意义的内存泄漏。当您进入下一页时，它们都会被清理掉，因此它不会永远累积，除非您永远不会离开该浏览器页面并一遍又一遍地执行相同的操作，其中涉及已删除的对象，但未删除的引用。

第三，jQuery 的 .data() 机制尝试为您在使用 DOM 对象时解决很多问题。

第四，在您设计的示例中，这不会造成内存泄漏，除非您在状态 2 中的图标数组不再有效或不再使用时不清理它。如果你清理它，那么在该数组中存储直接 DOM 引用就没有问题了。如果你不清理数组，那么即使数组本身也是内存泄漏，即使它里面有抽象的 uuid 而不是 DOM 引用。大多数时候，使用抽象引用只是比需要的工作多得多。

再说一次，即使你让它泄漏，只有当页面生命周期很长并且你重复创建和释放对象，但没有以引用随着时间累积的方式清除对它们的所有引用时，泄漏才重要。并且这样做足够使得它们引起的内存泄漏是有意义的。我一直在 JS 变量中保留对 DOM 对象的引用。我只是小心地确保当我不再需要它们时将它们清空，这样我就知道 DOM 对象可以在将来的某个时候被释放。