Pragmatic Uses of Monkey Patching in JavaScript
Have you ever worked with third-party code that worked well except for one little thing that drove you nuts? Why did the creator forget to remove those pesky console logs? Wouldn’t it be great if that API call could do just one more thing? If so then you know it can be difficult (or impossible) to get your changes implemented by the maintainer. But what about changing the code yourself? How can you do that if you don’t have the sources and don’t want to host them by yourself? Welcome to a journey into the world of Monkey Patching in JavaScript!
In this article we’ll look at what Monkey Patching is and work through some different examples, using it to change the functionality of a third-party widget to suit our requirements.
What is Monkey Patching?
Monkey Patching (hereafter referred to as MP) is a technique to override, extend or even suppress the default behavior of a code segment without changing its original source code. This is done by replacing the original behavior with a fixed version.
This article will use an existing feedback box widget which displays a simple, slide-able Popup, as seen in the figure below, containing a feedback form.
The source code was modified to include use-cases which act as the MP targets. By target I mean a specific piece of functionality, feature or, at the lowest level, method which we are going to patch.
Another modification I made was to remove the immediately invoked function expression (IIFE) surrounding the code. This was done in order to focus on the techniques of MP.
You can find the whole example, including the monkey patches discussed in this article, as a Plunker.
Isn’t Monkey Patching a Bad Practice?
Let’s get one thing straight before diving into business: Yes, MP is considered a bad practice — so is the evil eval, imperative programming, mutable data structures, two-way binding and so on.
If you use any of those there will likely be a decent-sized group to tell you you’re doing it wrong and should change this or that to fit a better condition. But as always, there are different tools and techniques available which vary in their suitability for certain scenarios. What seems extreme, crazy, or simply bad sometimes may be the last resort for a specific case. Unfortunately, because some practices are seen as bad you won’t even find a lot of articles describing how to do the wrong thing the right way.
The situation described here might be an unnatural one, driven to the extreme with a fake widget, to show what your options are. You, as the reader, then have to decide whether you like what you see or not. If nothing else, after reading this you will have a better understanding in order to argue against MP.
Targets for Monkey Patching
Before we dive into the techniques let us first examine what we’d like to achieve. The modified widget has a few code smells we’d like to work around.
Hardcoded background color
The first of them is a method called toggleError which is supposed to change the background color of an element based on a boolean parameter
FeedbackBox.prototype.toggleError = function(obj, isError) {
if(isError) {
obj.css("background-color", "darkgrey");
} else {
obj.css("background-color", "");
}
}
As you can see it sets the background-color property via the jQuery method css. That’s a problem since we’d like to have this specified via stylesheet rules.
Pesky console logs
While developing the widget, a console log was used give the dev hints about what currently is executing. What might be a nice approach during development, for sure is not the nicest thing to do in a production use. As such we need to find a way to strip all those debug statements.
Intercepting ad-server calls
The widget is great, but it has one strange behavior. Each time you initialize the script, it will make a request to a strange ad server and display unnecessary bloat on our page.
Continue reading %Pragmatic Uses of Monkey Patching in JavaScript%
LEAVE A REPLY
You must be logged in to post a comment.