Table Of Contents
- Introduction
- Destructuring
- Destructuring Imports
- A Cleaner Way To Destructure Imports
- My Conclusions
Introduction
I’ve been diving deep into the JavaScript ecosystem via TypeScript. One thing I’m observing in the more established engineering culture I’m part of now is the idea of cleaner code using things like destructuring. I am still new to this type of stack, so I wanted to talk about it and understand how we can better organize code.
This is a bait and switch since we’re talking about organizational principles in JavaScript. Both have the word ‘Script’ in the name, so I will stick with it.
Just a warning: I am new to this world. I don’t have a lot of expertise (yet) about what is or not cool in the ESM spec. So some info here might need further study.
Destructuring
Destructuring objects is a simple syntax that yields some helpful behavior. Destructuring allows you to unpack properties and values for arrays, objects, and classes. This is useful in organizing our code because we can avoid things like calling class or object names before their properties.
So we can go from doing things like this.
To something a little cleaner like this.
We can also do this in a way to avoid naming collisions for commonly named code that we will discuss further down.
Let’s see what this looks like.
First, we set up a new project and made some stuff to export.
Destructuring Imports
So let’s destruct some of these.
So the first thing I wanted to try was importing and destructuring these imports all in one line. So I was able to get something like this to work.
So first, we make constants that match the incoming object names. Then we utilize the require() syntax to pull in our objects. This assigns the two, three, five, and seven names to the constants we pulled in through the require statement.
This works for the demo project I was messing with, but it’s not the cleanest solution. You undoubtedly noticed the note above and TypeScript yelling at me by underlining words.
Regardless, we have access to the imported values.
A Cleaner Way to Destructure Imports
The cleaner way I’ve observed is something closer to this.
So these values are imported using the import syntax with a default import and then use a standard destructure syntax where you create constants matching the name of the objects you’re importing. So now we get this.
NOTE: Default imports are when you have things being exported via the default keyword like this import DefaultObj from ‘ObjMod’, where a named import is when you’re naming the things you’re importing via something like import { ObjName } from ‘ObjMod’.
This has been the convention I’ve seen most often. I like it; clean, easy to read, and TypeScript isn’t yelling at me.
My Conclusions
I will do things the cleaner way, but it comes down to what tool works best for that specific situation.
One thing I would note is including proper naming for object imports. Since we’re talking about taking away the class prefix, it might make sense to do something like this.
This combines my preferred way of destructuring along with syntax to rename the imported objects. This practice will help reduce the likelihood of collision bugs if I have several things named like config or something like that.
Destructuring is an excellent practice for clean code. Not like THE clean code, just code I think is well written and easy for the next person to read.
-George