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

问题描述

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

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

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

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

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

for ( let key in object ) {
}

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

解决方案

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

从2012年开始宣布hasOwnProperty支票的死亡:

我是否只面临由我自己的团队意外修改原型(或意外导入修改原型的库)引起的问题的风险?

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

还是我没有意识到的更大的麻烦空间?

否.

实际上，省略if (!object.hasOwnProperty(key))检查甚至可以解决一些问题并避免麻烦.并非您可能要枚举的所有对象都是保证具有一种hasOwnProperty方法或一种仍然是边缘案例，但它们并不依赖object)

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
}

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).

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 ) {
}

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.

解决方案

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.

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)?

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?

No.

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))

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

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