Objects as variable containers in JavaScript [closed]

Question

Recently I saw something like this in some code from a project I'm working on...

var domObjects = {
  $body: $('body'),
  $someDiv: $('.some-div'),
  $someOtherDiv: $('.some-other-div')
}

var constants = {
  CONST_ONE: 'some value',
  CONST_TWO: 'some value',
  CONST_THREE: 'some value'
}

As you already may notice this code intents to replace code like this:

var $body = $('body'),
    $someDiv = $('.some-div'),
    $someOtherDiv = $('.some-other-div');

var CONST_ONE = 'some value',
    CONST_TWO = 'some value',
    CONST_THREE = 'some value';

The idea behind this is to wrap the variables in a more "semantic" object so it could be easier to use, but I really have my doubts about to create an object just for cosmetic reasons.

• It this ok?
• There is any real advantage if I do the declarations this way?
• There is any disadvantage?

Answer 1

This style is not used because it's faster to work with since more typing is needed to access the variables, consider constants.const1 instead of just typing const1.

However, I like the style for at least these reasons:

• The variables are 'scoped'(so there's less possibility of a global collision)

• They are semantically encapsulated where they belong - which gives an explanation into which group they belong - It's easier for another dev who picks this up to make meaning of what those variables are

• They are easier to work with - If you want to capture all the properties of a group - e.g consider the object is department, you just iterate over the department which has all the relevant info you need

---

The DOM objects might be a little unnecessary to be put within an object, as for the rest I fully agree into wrapping them in an object like that.

Answer 2

It's perfectly fine: JavaScript lets you put any values inside of an object, which means you can use JS objects as "containers" for things like common variables or constants.

It's mostly a matter of personal preference. A construction like this is easier to pass around, so you don't constantly "requery" for things like $body or $document, but it can also hide what's in the object, so you don't know how much "room" your function input is taking up.

Is that a problem? Maybe, maybe not, that's up to whoever writes/uses the code. This question is (beyond the "is this okay" part, which it totally is) mostly a matter of opinion, guided by code style guides, and considerations about how to pack commonly used references.

There is one instance where this style makes a difference, and that's when unrolling switches. For instance:

function(input) {
  var a = "cat",
      b = "cow",
      c = "goldfish";
  console.log("testing multiple case identities...");
  switch(input) {
    case "small": return a;
    case "large": return b;
    case "aquatic": 
    case "fish": return c;
  };
  return false;
}

Instead of this check-by-check, we can be immediate:

var values = {
  "small": generateSmallAnimal,
  "large": generateLargeAnimal,
  "aquatic": generateFish
  "fish": generateFish
};

function(input) {
  console.log("direct jump...");
  return values[input]();
}

Done, no multiple case checks, just an immediate jump to the right thing.

Answer 3

It this ok?

Yes, this is totally okay. I have seen many JS libs group related values into an object. For example, many jQuery plugins store the configuration values into a settings object.

There is any real advantage if I do the declarations this way?

To me the major advantage is that related values are semantically grouped together. Imagine when we are coding in a modern IDE, I can simply type the objectName and [dot] to let the IDE lists out the variables of that particular group.

There is any disadvantage?

There is a performance difference as answered here, though it is not so important with modern browsers.