I’ve talked before about how I think the addition of the WordPress Theme Customizer (well, soon to be called the Customizer) is one of the nicest additions to the core application in a long time. I’ve also talked about how I fear the direction that some developers will take it.
Regardless, if you’ve worked with the Customizer long enough – especially when it comes to the JavaScript aspect of it – then you’ve likely noticed that you can end up writing relatively repetitive code especially when you’re working with something such as a list of items or something similar.
When you end up reaching this particular point, having too much of the same code with the only variations being a few strings ends up being a bit of a code smell.
In order to prevent this, it’s often better to write helper functions that abstracts the repetitive functionality into a single, ahem, function that you can call with the strings that are unique to your use case.
Here’s what I mean.
Redundancy in the WordPress Theme Customizer
Let’s say that your theme allows the user to add social icons for a number of different networks. This may include:
- …and whatever other popular network or icon you want to display
And in doing this, your implementation in the customizer allows the user to enter in usernames or URLs for each icon. The screen may look something like this:
Further, each of the social icons may be contained in some type of list or other container in which each icon is wrapped in its own element having its own ID even if the container is something like an anchor.
Next, let’s say that as the user enters information into the input element, the icons appear and if the user removes text, then the icons disappear. It’s easy to see how creating functionality for this could easily result in four functions, or one for each social icon depending on however many you opt to offer.
And that’s redundant.
Since each icon inherits the same behavior – that is, they appear with a URL or username and they disappear with empty text – then why not generalize the behavior into a function? This way, you can call the function for each of the social icons and it only requires a single line of code.
Generalizing the Functionality
To do this, a toggleSocialIconVisibility function can be written. It will accept three arguments:
- A reference to the jQuery function so that we can continue to use `$` when needed
- An `sId` parameter that references to the element’s ID attribute
- A `sControlID` parameter that refers to the Customizer’s control ID (which is defined on the server-side).
Ultimately, the final function will look something like this:
Granted, your mileage may vary depending on how you opt to hide icons. Above, I’m obviously using the classname of hidden to hide the values, but your CSS or frontend of framework of choice may use something else such as hide or invisible.
If that’s the case, then go with that.
Calling the Function
Next, all we need to do is make a call to the function for each of our social networks. We can do this during the document.ready function (and can do so using jQuery).
To do this, recall that we need a reference to the jQuery function, the ID of the element, and the Customizer control ID.
In keeping with the example above, let’s say that we want to make a call that allows users to define their Facebook URL. The social icon is wrapped in a container with the id attribute of ‘facebook’ and the theme’s control ID is acme_facebook_url.
To make a call to our above function, we can use the following code (note that the full snippet of JavaScript is used to show how to use this in the page load functionality):
Then, to include additional networks in the future such as, say, Google+, then you pay do something like this:
toggleSocialIconVisibility( $, '#google-plus', 'acme_googleplus_url' );
Easy enough, isn’t it?
The Bigger Picture
The whole point of bringing this up isn’t to show how to toggle social icons. That’s not exactly a unique or difficult problem, is it?
Instead, it’s meant to show how we should be refactoring our code as it relates to working with a relatively clean API. By that, I mean that I think the Customizer API is generally pretty good and I want to see more and more developers adopt it and integrate it into their work.
The thing is, if you’re just getting started with an API there’s a significant chance that you have an opportunity to refactor your code to make additions and maintenance to your work that much easier.
Obviously this is a simple example, but it’s one that demonstrates the point.
Leave a Reply
You must be logged in to post a comment.