3

In the eslint rule guard-for-in , use for in directly is incorrect. The good practice is 

for (key in foo) {
    if (Object.prototype.hasOwnProperty.call(foo, key)) {
        doSomething(key);
    }
    if ({}.hasOwnProperty.call(foo, key)) {
        doSomething(key);
    }
}

My question is when Object.prototype.hasOwnProperty.call(foo, key) and {}.hasOwnProperty.call(foo, key) will lead different result? Anyone can show a specific example?

Germinate
  • 2,008
  • 2
  • 14
  • 23

1 Answers1

4

They'll never1 lead to different results, which is why both of them are considered correct.

The object {} always inherits from the object prototype and has no own keys, so accessing the .hasOwnProperty method on it will get you what you want. And Object.prototype is a non-writable property of the global Object constructor, so it always refers to the object prototype as well.

Now, there are some cases where the expression does not do what you wanted it to do:

  • Someone did overwrite the global Object variable
  • Someone did shadow the Object identifier in your scope so that it doesn't refer to the global
  • Someone did overwrite Object.prototype.hasOwnProperty with something else
  • Someone did overwrite Function.prototype.call with something else

1: Obviously, the first two edge cases only mess with the Object.prototype reference, but they're still edgy enough to be ignored.

Bergi
  • 630,263
  • 148
  • 957
  • 1,375
  • I think they should be same, but why eslint give the good practice example like that? Could you explain why? After all, the four cases you listed are too edgy to be considered. – Germinate Apr 07 '17 at 06:52
  • Are you asking when they give a different result to `foo.hasOwnProperty(key)`? – Bergi Apr 07 '17 at 11:50
  • They're just both acceptable "good practice" patterns. One is better to understand but can be easier messed with, the other is shorter but harder to read. – Bergi Apr 07 '17 at 11:52