Typescript/Angular/ES6: can I finally let `hasOwnProperty()` die in for loops?

Question

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.

Answer 1

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)