Why Is It Frowned Upon to Modify JavaScript Object's Prototypes

Why is it frowned upon to modify JavaScript object's prototypes?

The problem is that prototype can be modified in several places. For example one library will add map method to Array's prototype and your own code will add the same but with another purpose. So one implementation will be broken.

Is it bad to modify a JS core object?

Whether is bad or not is quite debatable, I really like the point of view that @kangax gives us in this article:

• Extending built-in native objects. Evil or not?

At first he separates the extension of host and native objects, with host objects there are no guarantees, there's no a spec, and they have no rules.

Host objects are those that are provided by the environment, they are not part of the ECMAScript specification, for example DOM objects.

Extending native objects seems "less dangerous", he explores the problems of enumerability, which seems to be a problem, the for-in statement enumerates all object properties, inherited or own, if you add a property on Object.prototype for example, any object used with this statement will show the property name.

This statement is often abused to iterate over array objects, while it's purpose is to enumerate object properties.

At the end, I think the conclusion of this article is that extending native objects to shim standard compliant methods (e.g. ES5 Array methods (map, forEach, reduce, etc)) is encouraged, but extending natives to add custom non-standard compliant methods is discouraged.

Why is extending native objects a bad practice?

When you extend an object, you change its behaviour.

Changing the behaviour of an object that will only be used by your own code is fine. But when you change the behaviour of something that is also used by other code there is a risk that you will break that other code.

When method are added to the object and array classes in javascript, the risk of breaking something is very high - due to how javascript works. Long years of experience have taught me that this kind of stuff causes all kinds of terrible bugs in javascript.

If you need custom behaviour, it is far better to define your own class (perhaps a subclass) instead of changing a native one. That way you will not break anything at all.

The ability to change how a class works without subclassing is an important feature of any good programming language, but it is one that must be used rarely and with caution.

Javascript, Object prototype - avoid writing full path

One of possible approaches is to use the newly introduced Proxy that allows you to intercept arbitrary calls to object members.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy

An example from the MDN

var handler = {
  get: function(target, name){
    return name in target?
        target[name] :
        37;
  }
};

var p = new Proxy({}, handler);
p.a = 1;
p.b = undefined;

console.log(p.a, p.b); // 1, undefined
console.log('c' in p, p.c); // false, 37

React create own function on array

That modification is not recommended at all.

why?

When you modify a JS object prototype like Object and/or Array (in your case), you are adding a possibility of broke your code. Another library will add the same method(s) you add to the prototype but with another purpose so, your code is broken.

Object prototype modification is only being recommended to add functionality specified by the standard which is not yet supported, in other words, for adding polyfills.

You should modify your code:

class MyArray extends Array {  pushFn(nr) {    return [...this, nr, 1];  }}
const test = new MyArray();test[0] = 'test';
console.log(test.pushFn('one'));

---

Related Topics