Software Engineering in WordPress and Musings on the Deep Life

Bootstrapping JavaScript Files in WordPress

We talk a lot about the idea of having bootstrap files in WordPress plugins, which I think are great, but we seem to limit it to those files that are responsible just for starting our WordPress plugins.

Bootstrap JavaScript File

This isn’t exactly what I meant, but I dig the picture.

I mean, hooking into plugins_loaded and then instantiating some classes, setting up a service registry, or things like that are important. But what about other components that make up our plugins?

And by that, I mean what about our JavaScript files? Should they have their way to be bootstrapped?

Bootstrapping JavaScript Files

When it comes to working with WordPress, you’re more than likely going to be working with jQuery.

  • It’s a tried and true library,
  • It ships with core,
  • The UI library is available so that you can take advantage of other elements, as well.

And sure, this isn’t to discount the use of other libraries like Backbone, but when it comes to working with DOM manipulation on both the client-side and the server-side you’re less likely to use Backbone (and more likely to use jQuery).

Furthermore, there are already JavaScript standards for WordPress and I think, just as we should be using the WordPress Coding Standards with our PHP files, we should be linting our JavaScript with JSHint.

But this still doesn’t answer the question:

Should we be bootstrapping our JavaScript files?

First, I want to be clear that what I mean by bootstrapping JavaScript files is making sure that our document ready handler isn’t cluttered with all kinds of calls to manipulate the DOM.

Secondly, I’m of the mindset that there should be a JavaScript file related to individual tasks and that these should be put together into a single file during the build process. This is a topic for another post, though.

With that said, here’s a basic boilerplate for a jQuery-based JavaScript file to use with WordPress:

And here’s an example of what I’d like to avoid:

And this code isn’t even that great of an offender. But I still argue that too much functionality exists in the ready handler. Bootstrapping the JavaScript files, instead, would look something like this:

Obviously, I’ve left out the method implementation, but I’ve tried to make the point clear enough. There should be functions each of which have a responsibility, and they should call other functions they need when they need them.

The ready handler just invokes whatever function or functions should fire as soon as the DOM is ready. This ultimately makes the code that has so much potential to be difficult to read a bit easier to follow, to document, and to trace.

Sure, there are more sophisticated ways to write your JavaScript, and I’m not discounting those, but if you’re in the habit of throwing all of your code into the ready handler, consider smaller functions, starting only the ones that are needed, and then building them out from there.

In a future post, I’ll talk about separating the files and then combining them into a single file during the build process as that will take the benefits of this idea even further.

2 Comments

  1. Alain Schlesser

    Hey Tom,

    I completely agree that you should not have you entire code happen in the “bootstrapping” part, in whatever language you’re using. The first example you’ve posted is not much different than having everything happen in your plugin’s bootstrap file or your theme’s functions.php.

    However, I’m still not very happy with your second example. It’s definitely an improvement. However … it’s procedural code, and I have a general dislike of procedural code. You pretty much sum it up already:

    There should be functions each of which have a responsibility, and they should call other functions they need when they need them.

    I prefer to use other paradigms, like OOP or functional programming, because it is just to darn easy to mess up procedural code as soon as your codebase starts to grow.

    In the example above, I would have create an encapsulated object or module for whatever I want to have done (like a VideoEmbedHandler) and then pass control to this object/module from within the bootstrapping function to let it hook itself up to the system, like calling an init() method on it or similar. Only the VideoEmbedHandler itself should know onto which events it needs to hook itself.

    Otherwise, you still have to update code inside your bootstrapper when functionality of an object/module changes (and needs different events).

    • Tom

      The first example you’ve posted is not much different than having everything happen in your plugin’s bootstrap file or your theme’s functions.php.

      You’re right and I probably should’ve indicated more information in the post. The main idea is to introduce the idea of separating things out a bit.

      I’m planning to create an additional post on this topic in the future that takes the second example (which I know you mention momentarily) and breaks it out further.

      It’s easier to cover this kind of stuff in small steps, imho, which is why the post is on the shorter side versus trying to capture it all in a single, long article.

      I prefer to use other paradigms, like OOP or functional programming, because it is just to darn easy to mess up procedural code as soon as your codebase starts to grow.

      I agree especially on the front of when the codebase starts to grow — I like the idea of using something like the module pattern or maybe even encapsulating everything in a jQuery plugin (even though that has potential to get unwieldy if it’s not designed well or if it has too much going on in terms of functionality).

      Only the VideoEmbedHandler itself should know onto which events it needs to hook itself.

      This whole paragraph is really good. Maybe I’ll end up using this as a basis for the follow-up to this post. I’m not sure.

      Either way, it provides a really approach to breaking things out and making it more cohesive (with less coupling). 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

© 2023 Tom McFarlin

Theme by Anders NorenUp ↑