JavaScript Has Own Property: Keep Inheritance and Falsy Values Separate

The task

Inspect local preferences inheriting a theme default. Include an owned false flag and a field named hasOwnProperty to demonstrate why directly calling that name is fragile.

Runnable Node 22 example

const assert = require('node:assert/strict');

const preferences = Object.create({theme: 'light'});
preferences.enabled = false;
preferences.hasOwnProperty = 'user data';
assert.equal(Object.hasOwn(preferences, 'enabled'), true);
assert.equal(Boolean(preferences.enabled), false);
assert.equal(Object.hasOwn(preferences, 'theme'), false);
assert.equal('theme' in preferences, true);
assert.equal(preferences.theme, 'light');
assert.throws(() => preferences.hasOwnProperty('enabled'), TypeError);
console.log(`enabledOwn=${Object.hasOwn(preferences, 'enabled')}; themeOwn=${Object.hasOwn(preferences, 'theme')}`);

Expected output and explanation

The false enabled value is still an owned setting. Theme can be found by lookup and the in operator, yet is inherited rather than owned. Those are compatible results because the operations ask different questions.

The data field shadows the usual method name, so attempting to call it throws. The static Object.hasOwn operation does not depend on that field being a callable method. It is also suitable for a null-prototype dictionary when used with the intended object input.

Pitfall to check

An own property does not guarantee a valid value or permission to apply it. Validate allowed keys and value types separately. Counting all keys to define an empty object is a different task from checking one named setting.