🔍 Deep Dive: `Object.hasOwn()` Your Safer `hasOwnProperty` Alternative

Sushil Kumar — Wed, 23 Jul 2025 18:11:34 +0000

In JavaScript, checking whether an object has a property of its own (and not inherited from its prototype chain) is a common task.

Traditionally, developers have used Object.prototype.hasOwnProperty.call(obj, key) or the shorthand obj.hasOwnProperty(key). With ES2022, a new, more ergonomic method arrived: Object.hasOwn.

In this article, we’ll explore:

Why Object.hasOwn exists
How it compares to legacy approaches
Syntax and usage examples
Polyfill for older environments
Performance considerations
Browser & environment support
Best practices

📜 Background: The Legacy Approach

Before ES2022, to check if an object obj has its own property prop, you typically did:

if (obj.hasOwnProperty(prop)) {
  // …
}

However, this can break if obj shadows or deletes the inherited method:

const obj = {
  hasOwnProperty: () => false,
  foo: 42
};

obj.hasOwnProperty("foo"); // false — wrong!

To guard against that, the safest pattern was:

if (Object.prototype.hasOwnProperty.call(obj, "foo")) {
  // obj truly has "foo" as its own property
}

But the syntax is verbose and repetitive. Enter Object.hasOwn.

🚀 Introducing `Object.hasOwn`

The ES2022 standard introduced a static method on Object:

Object.hasOwn(obj, prop);

obj: The target object
prop: The property key (string or symbol)

It returns true if obj has its own (non-inherited) property named prop, and false otherwise.

Example

const user = { name: "Alice" };

Object.hasOwn(user, "name");    // true
Object.hasOwn(user, "toString"); // false (inherited)

🔄 Polyfill for Older Environments

If you need support in environments without Object.hasOwn, you can add a small polyfill:

if (!Object.hasOwn) {
  Object.hasOwn = function (obj, prop) {
    return Object.prototype.hasOwnProperty.call(obj, prop);
  };
}

Include this once at the top of your codebase (or in a setup file) to safely use Object.hasOwn everywhere.

⚖️ Performance Considerations

Under the hood, Object.hasOwn(obj, prop) calls the same algorithm as hasOwnProperty. Benchmarks indicate negligible difference in performance. The main advantage is readability and safety against shadowed properties.

🌐 Browser & Environment Support

Environment	Support
Chrome	93+
Firefox	92+
Safari	15.4+
Node.js	16.9+

For older runtimes, include the polyfill above.

🧰 Best Practices

Prefer Object.hasOwn for clarity and safety.
Use descriptive variable names:

  if (Object.hasOwn(cartItem, "quantity")) {
    // handle quantity
  }

Avoid in operator when you need to exclude inherited props:

  "toString" in {}            // true (inherited)  
  Object.hasOwn({}, "toString") // false

🏁 Conclusion

Object.hasOwn brings a concise, reliable way to check for own properties in objects—guarding against prototype pitfalls and improving code readability. By adopting this modern method (and polyfilling where necessary), you can write cleaner, more maintainable JavaScript.

🔗 Reference

MDN: Object.hasOwn

Happy coding! 👨‍💻👩‍💻

Demystifying React’s setState Batching: Why Your Counter Only Jumps Once

Sushil Kumar — Sat, 28 Jun 2025 12:02:49 +0000

Ever wondered why this sequence only bumps your counter by 1, not 2?

setCount(count + 1);
setCount(count + 1);
console.log(count); // still the old value!

It can feel like React’s hiding some magic, so let’s unpack what’s really happening.

1️⃣ Batched & Deferred Updates

React queues all state updates that happen inside the same event handler, then applies them in one render pass. That means:

You enqueue your changes immediately, but
The actual UI update happens after your function finishes.

So you don’t see the new state right away, and that’s why calling setCount twice doesn’t give you two separate renders.

2️⃣ Immediate Enqueue (No Hidden Timers)

Each call to setCount(...) runs synchronously. There’s no setTimeout under the hood. React simply adds your update to an internal queue. As soon as you invoke setCount, React remembers “we need to update state” and waits for the right moment to flush.

3️⃣ Same Snapshot, Same Result

Inside one render cycle, count stays at its initial value (say, 0). Both of your updates see that same 0 and each calculate “0 + 1.” When React finally processes the queue, it applies two identical updates, ending up at 1, not 2.

4️⃣ The Reliable Fix: Functional Updates

Whenever you need to base a new state on the previous value, use the functional form:

setCount(c => c + 1);
setCount(c => c + 1);

Here, each updater receives the latest pending state (c), so you reliably end up with +2.

💡 What to remember:

“Async” feel = React batches + defers renders

“Sync” reality = setter calls enqueue instantly

Pro tip: Always prefer functional updaters when relying on the previous state

🔗 Reference:
Queueing a Series of State Updates

Have you run into this gotcha? Share your experience or other React surprises below! 👇

Happy coding! 🚀

DEV Community: Sushil Kumar