Take your existing built-in objects and kick them up a few notches by learning how to extend them.
This is a companion discussion topic for the original entry at http://www.kirupa.com/html5/extending_built_in_objects_javascript.htm
I have experienced issue with extending built in object in javascript. This will cause issue, when your application going to loading different js references. In my case I extended the JSON with safeParse custom method and fb.js(External tracking purpose loading via analytics) reset the JSON object and my code started failing badly. I personaly feel extending built in object cause issues if you are working with multiple vendor js files loading in your application. Reference: Maintainable JavaScript: Don’t modify objects you don’t own - Human Who Codes
Extending prototypes is one of the best things about JS.
For a long time JQuery dominated all thanks to extending prototypes…
Most of the modern day JS methods started by somebody “hacking” the prototype…
If your concerned about name clashes use symbol() or don’t use so many libraries.
1 Like
Well, so, I have a funny anecdote that’s both amusing and something of a cautionary tale:
A few years back, I was working for a major medical corporation. The company itself isn’t relevant. What IS relevant is the team I was on was coding interpretive code to communicate with pacemakers via a websocket interface. Now, the data format pacemakers use is something called HL7, which looks for all the world like JSON. Problem is, the browser doesn’t SEE it as JSON. Which means every time you’d console.log something, it came out as one big honkin’ string, as though you’d JSON.stringify'd it.
So I get the bright idea: “Imma extend the Console prototype! JSON/HL7’s easy enough to parse, so I’ll just set it up so when someone does a console.log of one of these values, a copy of it is made in memory, I’ll recursively iterate the copied HL7, convert the copy to JSON, then log THAT out instead. So DevTools will do the whole collapsible tree thing and it’s easy to read!”
All I had to do was recursively loop over each key/value pair, identify its data type (Number, String, etc.) and rebuild it as a node in a Object. And what do you know: it worked! I ran a few more tests, checked it in to the repo, opened a PR with a detailed explanation, then took off a little early (it was a 4-day weekend, see?). A few hours later? Hey! Someone approved and merged it! Right on!
Fast forward to the following Tuesday. I come in to the office a bit early, sit down, and start coding. Business as usual, until I start dealing with the bugs in my backlog. I fix the first, crack open Dev Tools to verify… and everything explodes. Bizarre errors I’d never seen before. The more I tried to run them down, the worse they got. Moreover, others had arrived and were having similar issues.
It took me an embarrassingly long time to remember I’d been tinkering with Console. In fact it wasn’t until I finally noticed that the ONLY time any of us were getting issues was when we had Dev Tools open. As soon as it dawned on me (in horror), I went back to my desk and reverted the merge. With --force. At once, everything settled down. Better, nobody seemed to have noticed what fixed it, or where the issue began.
Quietly, I began to review my Console mod, trying to figure out WTF I’d done. It took me almost 2 hours to find it. See, to ascertain if the variable being traced was IN HL7, a ran a series of tests. One of which was if(variableToLog = Str){...} (Str being an extension of the String prototype, with a few additional properties added to it for HL7 convenience). See it?
Single equals. No idea. Musta fat-fingered. What I DO know is if you start reassigning all your variables to be copies of bloody String.prototype, but ONLY when your console is open, you get some REALLY weird behaviors. System-wide. Lotta devs leave their consoles open all the time. Lotta testers DON’T.
…so yeah: just make a copy of the ■■■■thing and you can extend that to your heart’s content. csl.log is even faster to type.