Typescript/Angular/ES6:我终于可以让 `hasOwnProperty()` 死在 for 循环中了吗? [英] Typescript/Angular/ES6: can I finally let `hasOwnProperty()` die in for loops?

问题描述

我一直不喜欢在 javascript 中循环对象时需要检查 hasOwnProperty():

I've always disliked the need to check hasOwnProperty() when looping over objects in javascript:

for ( var key in object ) {
    if ( !object.hasOwnProperty( key ) ) {
        continue;
    }

    // Now I can do whatever I needed to do
}

循环遍历对象中的键似乎总是浪费垂直空间，然后必须明确检查以确保这些键不是来自其他地方.我显然很熟悉为什么这在 javascript 中是必要的，尤其是由于旧的库有时会向原型链中注入东西(咳嗽 Prototype 咳嗽).

It always seems like wasted vertical space to loop through keys in an object and then have to explicitly check to make sure those keys didn't come from somewhere else. I'm obviously familiar with why this was necessary in javascript, especially due to older libraries that would sometimes inject things into the prototype chain (cough Prototype cough).

然而，据我所知，angular 没有这样的事情.Typescript当然也没有理由这样做.我无法想象任何现代 javascript 框架会.因此，在现代 Angular 应用程序(或任何现代 javascript 应用程序)中跳过此类检查有哪些可能的缺点?我是否只面临由我自己的团队不小心修改原型(或不小心导入修改原型的库)导致的问题的风险，还是有更多我不知道的麻烦空间?如果我尝试这样做，原型链还会以什么其他方式咬我?

However, to the best of my knowledge, angular does no such thing. Typescript certainly wouldn't have reason to either. I can't imagine any modern javascript framework would. As a result, what are the possible downsides of skipping such a check in a modern Angular app (or any modern javascript app). Am I only at risk of problems caused by my own team accidentally modifying prototypes (or accidentally importing libraries that modify prototypes), or is there more room for trouble that I'm not aware of? In what other ways might the prototype chain bite me if I try to just do this?

for ( let key in object ) {
}

我自己的测试没有发现任何问题，但我可能遗漏了一些明显的东西.是的，我知道 mondern js/ts 中的 Object.keys( object ) .它完成了工作，但我认为它不像 for ... in 那样干净，如果我可以让 hasOwnProperty() ，我宁愿使用它> 死.

My own tests haven't revealed any problems, but I may be missing something obvious. And yes, I'm aware of Object.keys( object ) in mondern js/ts. It gets the job done but I don't think it is as clean as a for ... in, which is what I would rather use if I can let hasOwnProperty() die.

推荐答案

在枚举普通对象和其他您知道没有可枚举继承属性的对象时，绝对没有理由包括此检查.你是对的，没有合理的现代框架对 Object.prototype 这样做.

There's absolutely no reason to include this check when enumerating plain objects and others that you know have no enumerable inherited properties. You are right, no reasonable modern framework does this to Object.prototype.

自 2012 年起宣布 hasOwnProperty 支票的消亡:-)

The death of hasOwnProperty checks has been proclaimed since 2012 :-)

我是否只面临因我自己的团队不小心修改原型(或不小心导入修改原型的库)而导致问题的风险?

Am I only at risk of problems caused by my own team accidentally modifying prototypes (or accidentally importing libraries that modify prototypes)?

是的.尽管解决此类问题的方法不是修改原型(或使属性不可枚举)，但不要添加 hasOwnProperty 到处检查.

Yes. Though the fix for such problems is not to modify prototypes (or to make the property non-enumerable), not to add hasOwnProperty checks everywhere.

或者还有更多我不知道的麻烦空间?

Or is there more room for trouble that I'm not aware of?

没有

实际上，省略if (!object.hasOwnProperty(key))检查甚至可以解决一些问题并避免麻烦.并非您可能想要枚举的所有对象都保证具有hasOwnProperty 方法，或者满足您的期望.检查的正确方法 - 在必要的情况下 - 一直使用 call:

Actually, omitting the if (!object.hasOwnProperty(key)) check might even solve some problems and avoid trouble. Not all objects you might want to enumerate are guaranteed to have a hasOwnProperty method, or one that does what you expect. The proper way to check - in cases where it is necessary - has always been with call:

if (!Object.prototype.hasOwnProperty.call(object, key))

(虽然当然有仍然是边缘情况，但它们不依赖于object)

(though of course there still are edge cases, but they don't depend on object)

这篇关于Typescript/Angular/ES6:我终于可以让 `hasOwnProperty()` 死在 for 循环中了吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！