javascript - MDN 上的 polyfill/shim 实现有多可靠

Question

我一直在浏览 Mozilla 开发者网络 (MDN) 上的 polyfill 实现，因为我需要其中的一些用于库。 我知道 shim.js 存在，但我没有使用它。

似乎 polyfill 的代码样式不一致。看起来它们是由社区以几乎“wiki”的风格编写的。

以String.prototype.contains为例

if(!('contains' in String.prototype)) {
    String.prototype.contains = function(str, startIndex) {
        return -1 !== String.prototype.indexOf.call(this, str, startIndex);
    }
}

这样实现对我来说似乎更合乎逻辑:

if(!String.prototype.contains) {
    String.prototype.contains = function(str, startIndex) {
        return this.indexOf(str, startIndex) !== -1;
    }
}

鉴于 JavaScript 是一种大小关键语言(因为为了网络传输，一切都应该尽可能小)，我的例子应该比 MDN 上的例子更有利，因为这样可以节省几个字节。

正如标题所暗示的，我想知道代码在 MDN 上的可靠性如何，我是否应该根据需要修改它以尽可能提供真正干净、微小的实现？

Answer 1

看来你的问题是指the article on String.contains() .

是的，MDN 是一个 wiki，因此其内容(包括代码示例)的质量可能会有所不同。但是，关于一般网络主题的内容(例如与扩展开发相对)通常都不错。不过，您不应该忘记使用常识。

MDN 上建议的 polyfill 和你的版本有三点不同:

• !('contains' in String.prototype) 与 !String.prototype.contains 检查属性是否存在:前者显然更可取。 in 运算符仅查找属性，没有副作用。另一方面，!String.prototype.contains 实际上会检索该属性的值并将其转换为 bool 值。这不仅速度稍慢，一些属性值如 0 将被错误地强制为 false。您可能不会注意到函数的差异，但在填充其他属性类型时，这可能会成为一个真正的问题。
• -1 !== foo 与 foo !== -1 的比较:这是一个品味问题，但有些人更喜欢前一种变体。在比较中始终将常量放在首位的优点是您不会无意中将比较变成赋值:编写 -1 = foo 而您的意思是 -1 == foo 会导致错误。另一方面，foo = -1 而不是 foo == -1 会成功，并且注意到代码中的问题可能需要一段时间。显然，如果您选择采用这种风格，则需要在所有代码中始终如一地使用它。
• String.prototype.indexOf.call vs. this.indexOf:前者防止 indexOf 方法在 this 对象被覆盖。因此，它更接近于原生 String.contains() 函数的行为。考虑这个例子:

var a = "foo";
a.indexOf = function() {something_weird};
alert(a.contains("f"));

String.contains 的本地实现和使用 String.prototype.indexOf.call 的 polyfill 将工作，即使 this.indexOf 是覆盖 - 但是使用 this.indexOf 的 polyfill 会失败。

总而言之，MDN 上提供的代码具有更多的故障保护功能。当然，这些在您的个人场景中是否需要。然而，为了节省几个字节而丢弃它们是错误的优化方法(“过早的优化是万恶之源”)。就个人而言，我更喜欢好的风格而不是效率，除非已知性能差异是相关的。