JavaScript Objects: Separate an Own Property from Its Value

Construct three controlled cases

Use Object.create with a prototype containing mode="practice". Add an own property note with the value undefined. Leave another name, such as absent, completely unset. These cases distinguish direct ownership, inherited availability and absence while keeping the fixture small enough to inspect by hand.

Ask the ownership question

Object.hasOwn(settings, "note") should be true, while the same method returns false for mode and absent. An own property with an undefined value is still an own property. Record the Boolean result separately from the value printed by a direct property read.

Compare the prototype-aware question

The expression "mode" in settings is true in this fixture because in checks the prototype chain. That does not contradict the false Object.hasOwn result. One asks whether the property is available through that chain; the other asks whether it is defined directly on the object.

Remove the own property deliberately

Delete note and repeat both its direct read and the ownership test. With no matching prototype property, the direct read remains undefined, but Object.hasOwn now becomes false. This is why a test of the returned value cannot always reconstruct whether an own property existed.

Keep the contract explicit

• Use an own-property check when direct ownership is the requirement.
• Use a prototype-aware test only when that is the intended question.
• Validate the accepted value and type separately from presence.
• Check runtime support before adopting an API in a target application.

Keep the object lesson separate from trust

A present property can still hold an invalid value. Save the fixture and its three observation columns before extending the example to a form or API boundary. The exercise supports JavaScript objects in the existing Full Stack learning path without treating inheritance checks as a complete input-validation system.