Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

When should I use my own namespace and when should I extend native js objects?

I am in the process of refactoring my code. I'm having trouble deciding on how exactly to implement a couple utility functions I have. Specifically, if certain functions are better off in my personal namespace or extending js Objects directly.

Example of extending native JavaScript Objects

(is this the proper term?).

String.prototype.prettyDate = function(){
  return (this.substr(5,2) + '/' + this.substr(8) + '/' + this.substr(0,4));
}
var myString = "2010-12-27";
//logs 12/27/2010
console.log(myString.prettyDate);

Example using my own namespace

var myNamespace = (function(){
   var my = {};
   my.prettyDate = function ( dateStr ){
      return (dateStr.substr(5,2) + '/' + dateStr.substr(8) + '/' + dateStr.substr(0,4));
   }
return my;
}());
var pretifiedDate = myNamespace.prettyDate('2010-12-27');
//logs 12/27/2010
console.log(pretifiedDate);

Questions to consider

  1. When is a utility justifiably inserted into a native JavaScript Object?
  2. How can I tell when a utility is better off being in my own namespace?
like image 317
Derek Adair Avatar asked Dec 28 '10 03:12

Derek Adair


3 Answers

  1. Almost never, because of:

    a/ possible conflicts with other libraries

    b/ extended functions are iterated as properties by in operator, which poses problems unless filtered out by hasOwnProperty (which is not commonly used)

    You can justify this for small, one-script works, but only if you 200% sure that no one, never ever will try to reuse that code somewhere. In such case use it only for functionality which spans more than one module of your code. Extending String with trim() - ok, extending String with prettyDate() - doubtful, extending Object with displayAsPageHeader() - scary.

  2. So, almost always.

like image 129
ts. Avatar answered Nov 18 '22 21:11

ts.


Watch this video:

  • http://ejohn.org/blog/building-a-javascript-library/

John Resig reckons that extending native objects is a recipe for disaster, particularly when a framework or application is likely to grow into something that does far more than was initially intended.

like image 44
karim79 Avatar answered Nov 18 '22 20:11

karim79


Unfortunately, this question doesn't have a "right" answer. It's a good discussion to have but I fear it'll be closed here. Whether native objects should be extended at all is a subjective debate, and if you accept that it's conditionally okay the answer to "when?" is "depends."

If you have control over its use and whether it will collide with other code, there's really no reason you shouldn't. It can be quite convenient and may reduce code size significantly.

Where there's a real problem with extending native objects is when you have other code running alongside your extension, which may be expecting a different extension in with the same property name, or which may be carelessly using for(var i in obj) without guarding against extensions up the prototype chain.

like image 2
eyelidlessness Avatar answered Nov 18 '22 21:11

eyelidlessness