Why Do JS Devs Hate Namespaces?
Tags: javascript, codequality
Published: 2020-12-06 04:00:49

I'm a huge believer in self-documenting code.  In fact, I've already written about the idea that comments are a code smell - because I should just be able to _read_ your code and understand what it's doing.  I'm also a big fan of more _descriptive_ code - meaning, variable/object/function names that (usually) avoid abbreviations and try to state, clearly, what they are representing.

So I've always been a little bothered by (what I perceive to be) a lack of namespacing in JS.  This may be because, as an "older" dev, I have experience in numerous languages - and many other languages make heavy use of namespacing.  It may be simply because I'm verbose as hell.  But for whatever reason, I often look at JS code and feel - more than in other languages - the naming conventions are too simplified.  Sometimes, to the point of confusion.

Granted, I don't think that JS devs have some genetic condition that precludes them from understanding/using namespacing.  Rather, I believe there are some factors unique to the JS community that have fostered this "condition".  Allow me to explain...
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/z2u5mecdty84r1e7qrw1.jpg)
## Class Warfare
Going all the way back to my _second_ post on this site, it was all about JS's "class warfare" (https://dev.to/bytebodger/the-class-boogeyman-in-javascript-2949).  Since then, I've written multiple pieces that touch on this aspect of JS dogma.  As a React dev, the "Classes R Bad" mantra hits particularly close to home.

I won't bore you by trying to regurgitate all that content here.  You can look through my past articles if you're at all interested.  But there is one beneficial aspect of classes that I never even bothered to outline before:  They create a natural opportunity for namespacing that, when used properly, can make your code much clearer.

For example, in a previous article I outlined a runtime validation library that I wrote for myself to ensure the integrity of all function inputs.  Since this library needs to do many different type of validations, it's logical that it contains many different functions.  But the library itself is part of one unifying _class_.  

Why did I choose to leverage an evil, filthy, unconscionable `class`??  Well... because I now have code that looks like this:

```javascript
import { allow } from '../../classes/allow';

const populateLikelyDuplicates = (pairs = [[]]) => {
  allow.anArrayOfArrays(pairs);
  // function logic here...
}   
   
const updateSelectedPlaylist = (event = eventModel) => {
  allow.anInstanceOf(event, eventModel);
  // function logic here...
}
```

The validation library lives in a utility class.  The instance of the class is stored in `allow`.  And thus, when I import the utility class and use it in my code, it reads _as natural language_.  And this clarity is made far easier by the natural _namespacing_ that's afforded by the class.

To be absolutely clear, I realize that you don't need to use classes to get this namespacing.  You could just save all of those validation functions under a single plain-ol' object.  Then you could name the object `allow` - and you'd still have all the same benefits.  But I've come to believe that JS devs' aversion to classes has made this approach fairly rare.

Don't believe me?  Well, think about how you would "normally" consume a validation library like mine.  The library would be encapsulated within an NPM package.  Then, when you wanted to use any of the particular validations, you would need to import them one-by-one.  So your code would probably look something closer to this:

```javascript
import { arrayOfArrays, instanceOf } from 'function-input-validation';

const populateLikelyDuplicates = (pairs = [[]]) => {
  arrayOfArrays(pairs);
  // function logic here...
}   
   
const updateSelectedPlaylist = (event = eventModel) => {
  instanceOf(event, eventModel);
  // function logic here...
}
```

Now, I'm not going to try to tell you that the code above is, in any way, "unreadable".  But I believe strongly that, simply by removing that _namespace_ value of `allow`, we've made the code a bit less self-explanatory.  

This will also lead to a potentially burdensome `import` statement if we keep adding different validations to the component.  But when you use a class, you don't need to bother with individually importing each of the validations.  You just import `allow`, and you're done.

Of course, I could "fix" the lack of natural-language namespacing by making the names of each validation function more explicit, like this:

```javascript
import { allowAnArrayOfArrays, allowAnInstanceOf } from 'function-input-validation';

const populateLikelyDuplicates = (pairs = [[]]) => {
  allowAnArrayOfArrays(pairs);
  // function logic here...
}   
   
const updateSelectedPlaylist = (event = eventModel) => {
  allowAnInstanceOf(event, eventModel);
  // function logic here...
}
```

But this runs into a problem, because my validation library is designed _to be chained_.  So, with my original `allow` library, I can do this:

```javascript
import { allow } from 'function-input-validation';

const doSomething = (userId = 0, name = '', isActive = false) => {
  allow.anInteger(userId, 1).aString(name, 1).aBoolean(isActive);
  // function logic here...
} 
```

But if we want to strip the leading `allow.`, the new code looks like this:

```javascript
import { allowAnInteger, allowAString, allowABoolean } from 'function-input-validation';

const doSomething = (userId = 0, name = '', isActive = false) => {
  allowAnInteger(userId, 1).allowAString(name, 1).allowABoolean(isActive);
  // function logic here...
} 
```

Umm... _yuk_.

IMHO, couching everything in that descriptive `allow` wrapper makes the code more readable - while at the same time keeping us from having to repeat `allow` in every function name.  Yet it feels to me like I rarely see this in JS environments.
<br/><br/>


![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/jtnhkideo8asilkhpun5.jpg)
## Reckless Destructuring
I think most JS devs would define destructing as a "net good".  And I'm certainly in that crowd.  But _some_ JS devs have come to embrace destructuring to the point that they believe **_ALL THE THINGS!!!_** should be destructured.  I'm definitely not in _that_ crowd.

Lemme be honest.  I've gone back-and-forth on this one over the last several years.  When destructuring was first introduced, I looked at it and thought, "Yeah... that's nice.  Not sure how much I'll really _use_ it.  But it's nice."  Then, about 18 months ago, I went through a phase where I was hellbent on destructuring **_ALL THE THINGS!!!_**  Now... I've cooled _wayyyy_ off on the destructuring.  

Why do I do _less_ destructuring nowadays??  Well, destructuring effectively robs a variable of its _context_.  When you're reading code, it's crucial to be able to quickly understand a variable's context.  

Think of it like this:  Let's say that your name is Joe.  If I tell someone that I was just robbed by Joe, and that's _all_ the information I can provide, I might as well just yell my complaint into the wind.  Because "Joe" isn't even _close_ to the level of info the authorities need to investigate the crime and make an arrest.  If I said I was robbed by Joe Schmidt, who lives at 101 Main Street in Palookaville, Florida, and his SSN is 999-99-9999."  Well... that's more than enough info to get the cops into a full-fledged investigation.  When you destructure your objects, it's like you're limiting all of your identifiers to "Joe".

To be clear, I'm not trying to claim that destructing is somehow a _bad_ thing.  I use destructuring all the time.  You should, too.  It can make convoluted code read much clearer.  The classic use-case for destructing is when you have a deeply-nested object, something like this:

```javascript
const salesTax = price * tax.rates.states.florida.counties.duval.cities.jacksonville;
```

The snippet above can be particularly onerous if you need to refer to the Jacksonville sales tax rate multiple times.  So it's clearly easier (and "cleaner") to destructure that value into a simple variable name.

But there are many other scenarios where I find destructuring to be a _detriment_ to the code's clarity.  That's because, when you destucture an object, you're stripping the nested values _of context_.  

For example, in the snippet shown above, let's imagine that we just destructure that value down to `jacksonville`.  Then, at some point further down in the function, you're reading the code and the first instinct is to think, "Jacksonville _what_?"

Here's a tangible example that I run into all the time as a React dev:

```javascript
const doSomething = (userId = 0) => {
  if (userId === props.userId) {
    // do some logic here
  }
}  
```

See what's happening here?  In the "legacy" way of handling React components, you had an object of values that may-or-may-not have been supplied to the component.  Those values always lived in a `props` object.  And quite frankly, I found that `props` nomenclature to be incredibly useful when reading the code.

In the example above, there's some helper function _inside_ the component, that expects a `userId`.  But there's also a `userId` that was passed into the component.  And I frequently find myself having to compare some temp value against the original value that was supplied to the component.

In these cases, I truly enjoy having the `props.` moniker in front of all the component's passed-in values.  It allows me to easily sort out what is a temp value in memory, versus what was supplied to the component from its caller.  If you're hellbent on destucturing **_ALL THE THINGS!!!_**, it can quickly become confusing when you're trying to read through the code.