Adventures In TypeScript: Destructuring and Code Organization

I've been learning more stuff about organizing TypeScript and JavaScript!

Table Of Contents


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 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.

Object Name

To something a little cleaner like this.

Destructured Property

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.

Prime Numbers module. See there's TypeScript right there! Why are you yelling at me?

Round Numbers module. And here's even more TypeScript! OK, there's no types. You're a genius, we get it.

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.

Require Destructure

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.

Prime Numbers Console

A Cleaner Way to Destructure Imports

The cleaner way I’ve observed is something closer to this.

Cleaner Destructur

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.

Round Numbers Console

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.

Good Naming

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.


Full Demo Code