为什么要使用DOMStringList而不是数组？

Question

我最近发现了DOMStringList，可以在IndexedDB的存储名称列表中找到。看起来DOMStringList只是一个简化版本的数组，只有两个方法item()和contains()。没有像数组上那样有用的方法，如indexOf、filter、forEach等。那么为什么要使用这种对象？DOMStringList有哪些优势呢？

- Luke

---

我的假设是它们在 DOM 字符串方面更有效（例如保证所有元素都是 DOM 字符串，而不必能够存储任何东西），并且 JavaScript 不会将其转换为效率较低的数组，除非您明确告诉它这样做。 - Samathingamajig

可能是因为数组包含方法并不总是被支持，但 DOMStringList 自 Chrome 版本一就存在了。 - markfila

Answer 1

存在 DOMStringList 是一个历史意外。在现代 API 中，同样的用例可以通过使用 Array 实例来满足。

它被引入到 Web API 中，因为我们需要一些类似于数组/列表的东西，但不能被修改。"不能被修改" 部分很重要，因为对于可修改的数组在场景中会出现什么情况并没有好的答案。

db.objectStoreNames.push("foo");
db.objectStoreNames.push(notAString);
db.objectStoreNames.shift();

当第一个使用DOMStringList的API被引入时，设计API的人不知道如何将其与Array配合使用。因此，他们设计了DOMStringList。它用于一些API，即location.ancestorOrigins和db.objectStoreNames。

但后来，设计此类Web API的人发现如何引入不可修改的数组。这实际上需要两次尝试：

• 介绍了使用 frozen Array 实例的方法，通过 FrozenArray<> Web IDL 类型。请参阅whatwg/webidl#52 和其中链接的错误。

• 引入了使用 proxies 包装 Array 实例的方法，通过 ObservableArray<> Web IDL 类型。请参阅whatwg/webidl#840 和其中链接的错误。

这两者的区别在于，冻结的Array甚至无法被浏览器修改；而代理Array可以被浏览器修改（如果相关规范允许的话，甚至可以由Web开发人员进行修改）。

那么，我们能否使用DOMStringList中的所有内容来使用这些现代化的解决方案？不行。因为有一些代码依赖于db.objectStoreNames.item()和db.objectStoreNames.contains()这些方法，如果我们转换到实际的Array实例，这些代码将会出错，因为Array实例没有这些方法。

因此，如果我们想要完全消除Web平台上旧的类似数组的类，并开始使用真正的Array，我们可能需要第三种Array包装类型。它将是Array的子类，带有一个或两个额外的方法，并可能有一个代理包装。目前还没有人朝着这个方向迈出步伐。

您说还有其他类似数组的遗留类？是的：除了DOMStringList之外，我们还有TouchList、AnimationNodeList、CSSRuleList、DOMRectList、FileList等等...请参见此具有item()方法的Web平台类列表，其中大多数（但不是全部）都是这种类型。

- Domenic