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:

  • Twitter
  • Facebook
  • Pinterest
  • Instagram
  • …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:

Social Icons in the Theme Customizer

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:

  1. A reference to the jQuery function so that we can continue to use $ when needed
  2. An sId parameter that references to the element’s ID attribute
  3. 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.


Join the conversation! 2 Comments

  1. That’s right Tom. I’ve been using a custom framework for a while, not so soon ago we dropped that in favor of Customizer and that was the best decision we made.

    That not only made learning through settings easier for customers, but also requires less effort for users and developers—it resulted in almost 20-30% reduction in support tickets.

    And with upcoming changes in 4.0, it’s totally worth switching for!

    • That not only made learning through settings easier for customers, but also requires less effort for users and developers—it resulted in almost 20-30% reduction in support tickets.

      That’s an awesome figure. I’ve always been curious as to how much a difference in support that using the Customizer makes as it relates to those who a larger customer base.

      And regarding 4.0, I agree. It’s only going to get better :).

Leave a Reply