Как проверить, есть ли у объекта ключ в JavaScript?

Соответствующие тесты: jsperf.com/checking-if-a-key-exists-in-a-javascript-array

одна проблема, которую я обнаружил с hasOwnProperty в firefox, - это возврат false для унаследованного ключа

@maldy: разве не в этом весь смысл has**Own**Property?

для унаследованного ключа вы можете проверить так, если (myObj.key.key) он вернет true, если он существует

ESLint отклоняет это как Do not access Object.prototype method 'hasOwnProperty' from target object.

@CJBrew это может быть потому, что у вас есть флаг eslint нет встроенных прототипов, и в этом случае вы все равно можете использовать его, выполнив {}.hasOwnProperty.call(object, "key")

Идея заключается в том, что если вы выполняете myObj.hasOwnProperty(), вы позволяете myObj перехватывать этот вызов (и, таким образом, может испортить вашу логику) ... Однако это также можно рассматривать как преимущество, которое myObj может выбрать для этого. Лично я считаю, что ESLint очень внимателен в этих вопросах.

Стоит отметить, что если myObj.myKey действительно был объявлен как undefined (по какой-то безумной причине), то myObj.hasOwnProperty('myKey') вернет true.

Я оставлю это здесь для всех, кто задается вопросом, почему ESLint жалуется на eslint.org/docs/rules/no-prototype-builtins

это антипаттерн imo, свойство собственный должно использоваться только для этого уровня.

Причина, по которой in считается плохим, заключается в том, что он выполняет поиск по всей цепочке прототипов.

и даже лучше - if (myObj && 'key' в myObj)

что не так с поиском по всей цепочке прототипов (если вы не знаете, что не хотите этого делать по какой-то причине)?

@reconbot, в обычных объектно-ориентированных языках вы часто вызываете методы, определенные в родительских классах. Что не так, делая то же самое в js? Означает ли это, что сами цепочки прототипов js плохие? Некоторые люди действительно могут их использовать.

мог бы сделать вот так Object.keys (ObjectInWhichYouwantTocheckTheKey) .includes ('key‌ InObject') :) ура

TypeScript, похоже, не рассматривает hasOwnProperty или in как защиту типа.

Uncaught (в обещании) TypeError: правая часть 'in' должен быть объектом, получившим неопределенное значение

Вероятно, следует избегать использования hasOwnProperty и делать Object.prototype.hasOwnProperty.call(myObj, "key");. Что, если ваш объект имеет фактическое свойство, называемое hasOwnProperty, или хуже, если клиент добавляет это свойство? Вот еще контекст: eslint.org/docs/rules/no-prototype-builtins

@Nishant - Производительность концерна? Потому что в противном случае кажется, что была бы желательна проверка всей цепочки прототипов ... вы выполняете эту проверку, потому что хотите знать, существует ли она, прежде чем вы попытаетесь получить к ней доступ, предположительно, и доступ к ней будет проходить через всю цепочку прототипов, если необходимо ...

@ArtOfWarfare, да, производительность - это проблема. Я не делал (тяжелых) OOPS в JS, поэтому хотел бы услышать мнение экспертов по этому поводу. Я согласен, что это может быть полезно в зависимости от варианта использования :-)

@jononomo и другие: это проблема, если вы используете объект как карту. Если вы, например, хотите убедиться, что элемент был записан только один раз и более новый перезаписан, и использовать in, вы не сможете хранить ключи, которые равны имени метода прототипа.