Be wary of prototype naming that can cause potential conflicts with one of the named objects.
I have talked about using a non-emumerable property when defining a prototype, but what will happen if your prototype name conflicts with a prop name? You will loose quite a bit of hair - that’s what happens.
Object.prototype.color = () => {
return "blue";
};
let apple = { name: "apple", color: "red" };
console.log("invoke color function ", apple.color());
// TypeError: apple.color is not a function
console.log("invoke color function ", apple.color);
// red
I don’t know of any way of preventing this other than “being careful”. What we end up doing is to use a name space prefix if we define prototypes. By convention, name spaces are not used in the object props.
Object.prototype.tfColor = () => {
return "blue";
};
let apple = { name: "apple", color: "red" };
console.log("invoke color function ", apple.tfColor()); // blue
console.log("invoke color function ", apple.color); // red
These instances are extremely rate as they are since I am not that careful in keeping my code DRY. I seldom use prototypes in the way described above. Falling back to reusable functions/classes or using utilities provided by a framework just seems more natural.