Since the current trend of “fat-client” web applications, JavaScript has forced it’s way into the toolbox of many developers. If you’re like most people, you cobble together scripts you need based on examples you find on the internet. After all, it looks a lot like that language you’ve used day in and day out for the last 15 years so how hard could it be? Unfortunately, most of the examples on the internet aren’t very exemplary. It’s time we had a candid chat about anonymous functions.
One of the first things you learn about JavaScript is that you can pass a function as an argument to a function (if you didn’t learn that, take a moment to ponder it, then clean the brain bits off the wall). It looks something like this:
This is an all-too-common example of a jQuery event binding. It binds the function passed to click as the event handler for the click event on the .arrow element. In plain English that means the function will be called when the .arrow element is clicked. This code works just fine but it’s unsustainable.
For one, this function has to be read every time someone wants to find out what happens when you click on the .arrow element.
Also, if something goes wrong with this function, the call stack will report the error happening in (anonymous function). If you use this style of callback throughout your application the error could be anywhere. Modern browser developer tools help mitigate this problem but it’s nice to know exactly what broke your application.
Most importantly, this callback is now tightly coupled to the event. It is way too easy to end up duplicating code with this style. Not only that, but this style encourages stuffing more and more functionality into this callback as the business requirements change. Granted, this is a trivial example but code like this is 90% of JavaScript programs (percentage not based on any actual science).
Let’s look at a very simple way to fix this problem and get much more readable and reusable code:
By pulling out the anonymous function and giving it a name, we’ve immediately gained more clarity in the code, increased the re-usability, and encouraged decoupling between the event and the code that executes as a result. It becomes even more clear when we use the preferred jQuery on method:
It’s practically a sentence. As business requirements change, we’re less likely to jam more code into the callback and more likely to write additional functions to accommodate new functionality. At which point we may even refactor a bit further to this form:
This style completely decouples business logic by specifically creating a composed “handler” function. Any other code can now call these functions outside of the context of clicking on the .arrow element and the desired behavior is preserved.
Obviously this is a bit much for such a trivial example but you get the idea. Writing JavaScript callbacks like this will keep you sane when your application reaches a significant size. As a rule I always pass named callbacks in favor of anonymous functions in my JavaScript and my applications are better for it. There are times when you need to bend these rules, but if you avoid anonymous functions I promise you and your teammates will be much happier developers.
Tandem is chicago custom software development company with practice areas in digital strategy, human-centered design, UI/UX, and web application and custom mobile development.
