It’s not an insult. Don’t take it that way. It’s just a reality, and it’s not your fault.
Once you’ve got a f***ton of JS code on your website though, it’s gonna be harder to maintain, organize, read, or even find what you need. It’ll be more prone to breaking, and harder to debug. And you’ll be hiring someone like me to come clean it up and teach you how to do it better. While I enjoy money, there are some helpful JS techniques that can make your life easier in the meantime.
Namespaces and encapsulation exist in just about any object-oriented or object-based programming language. They’re simple to understand, and can go a long way in making your code more organized. Learn what I’m about to teach you, make it into a habit, and then come back and thank me for it.
Ever live with a hoarder? I haven’t, but I’ve lived with messy people. It drove me nuts. Given, I’m more crazy than most when it comes to neatness. But still. Live in an apartment that is a perpetual mess, and you’re guaranteed to be slower at getting anything done. Same deal for a messy desk at work.
If your code is a mess, it’s going to slow you (and other developers) down big time. Sometimes you’ll realize it, sometimes you won’t. It’s the kind of thing where you’re so used to working with the status quo that you don’t know what “better” feels like.
It’s far more noticeable when you’ve got components you want to make reusable. You take the function and put it in a separate file, and something breaks. You make it work, but no one knows where to find it. There’s no logical separation.
Or you have something important and you want to add automated tests to it. But you can’t, because your functions only run on the page you created them on.
But I use CommonJS/AMD. Do I still need to learn this?
Yes. Even though these make your JS more modular by themselves, complex classes will still have a lot of moving parts within them. Namespacing is still very, very useful.
But I use AngularJS/React/whatever. Do I still need to…[*interrupts you*]
YES! Complex code always needs organization. Frameworks use their own namespaces (e.g., angular.module() or React.createClass() among tons of examples). Your code, as it gets complex, will need them too.
Where Namespacing Helps
Here are a few examples of the types of code namespacing can make better, and why.
Grouping Loose Methods
Encapsulating a UI Component
When an HTML element has a certain behavior and information attached to it, it’s very logical to keep its behavior and data in one place. Here’s an example of a simple select box that gets populated with data, and an event gets attached to it.
Here the data (the countriesIveBeenTo array) is a global variable which can get overwritten. Also this code is heavily tied to the #countries element; there’s no way we can reuse it for multiple select boxes.
But putting this component in its own namespace, we can keep the data inside the component so it can’t be overwritten by a variable with the same name. I’ll go more into detail on this approach in another article. But just know that this keeps our data private, and makes this module far more reusable:
Reducing Conflicts & Data Overwriting
I sure have. At least a hundred times apiece. Know what happens when you accidentally create the same variable twice in the page?
Say you’ve got a login form with a big div above it containing any error messages:
Guess what? When the user clicks submit, the form field disappears instead of the error container. This could have been avoided if the components were namespaced:
You access them like so:
You can nest them as deep as you want:
You can build them gradually, rather than in one shot (this helps you separate things into different files):
Namespacing with jQuery
If you prefer using a jQuery structure, you can use similar namespacing via the $ object. Using the example above, it’s the same deal:
I tend to avoid this approach except for functions that follow the jQuery function convention (i.e., working off of DOM elements and returning a jQuery object). My keeping a separate top-level namespace (MyApp or MyCompany), it makes it a lot easier to distinguish your app’s custom code from that of jQuery plugins.
When looking at a messy JS codebase, I usually try to group things in logical categories. Patterns like this are common:
Every once in a while it makes sense to take another look at everything as a whole and reassess whether the organization makes sense. If it doesn’t, see what might make better sense & do some refactoring.
For a touch of elegance, for many years I’ve used a utility function I got from Ext.js many years ago. With one line of code, you can easily ensure the namespace you need gets instantly created, no matter how many levels deep:
Note that this function should be defined with your top-level namespace, before you define anything else.
You use the namespace method like this, inside each module’s file:
That’s my intro to namespacing. Lots of detailed info for a very simple, but powerful concept. Never write code without it.