Get in touch

Get in touch with Binary

Binary Studio website uses cookies to enhance your browsing experience. By continuing to use our site, you agree to our Privacy Policy and use of cookies.

Learn more more arrow
Vladyslav Zubko 04.08.2021

JS and everyday data structures

Let's start with a quote that once changed my life. I am sure that this quote and its understanding will also change yours if you have not heard it yet.

Bad programmers worry about the code. Good programmers worry about data structures and their relationships. [Linus Torvalds]

We will talk about data structures, but first, it is impossible to talk about them without mentioning algorithms. 

Algorithms are the steps we need to take to solve a problem. Data structures are organized data with efficient and convenient access to them.

Programming is always = algorithms ➕ data structures.

When solving a problem, it should be kept in mind that choosing the right data structure may be a solution for the problem (no need to write any code)

Data structures in JS

JS has two basic data-structures that can be reused in different ways depending on the requirements. Therefore, they support a large number of methods of different structures which would be separate in other program languages.

  • Object (Enum, Map, Graph, etc);
  • Array (List, Stack, Queue, etc).

Let's get started!

We will use this user type for further examples:

Do not worry if you are not familiar with TypeScript. The example of the type is given so that you understand the approximate structure of the user.

The task

Let's imagine that we have a task — we need to display a list of users using the appropriate emoji by the user's gender. For now we have only two options — male and female.

It might look like this:

That's it. The task is done. Buuut... we can do it better.

Let's imagine that in our code there will be or there already are places where we check something by the user's gender. We duplicate the code. It is not good. Also if we use *just a string* all the time, sooner or later, we will make a mistake. In fact, such errors are not very easy to find.

Let's solve this task too. We will protect ourselves from this. We will use a single source of truth — CONSTANT's.


CONSTANT s are used to describe data that is known *before the start* of the program and that *should not be changed* during the execution of the program.

When associated with an identifier, a constant is said to be "named," although the terms "constant" and "named constant" are often used interchangeably.  [Wikipedia]

The constant can be declared with any keyword for variables (var, let or const), but const is commonly used.

Constants are a very important and popular approach to organize program code. And there are several conventions among developers for them:

  • Constant must be declared at the top of the program/module (after imports, if any);
  • Constant must have a name in capital letters;
  • Constant must not be redefined anywhere in the program.


Here is an improved solution for our task:

Much better, but we can improve it even more.

Have you noticed that we duplicate GENDER_TYPE in the name? It is not critical, but annoying. Also if we needed some values, we would have to import each constant separately.

It would be cool if there was a data structure that would help us with this as well. And there is such a structure — Enum.


Enum (enumeration) — a data structure that is used to enumerate a set of fixed values (set of constants).

Other programming languages have a separate data type for Enum. But JS does not have this type of data (at least for now, more on that below). The regular object is usually used to imitate Enum in JS.

For this structure, JavaScript also has conventions among developers:

  • Enum must start with a capital letter;
  • Enum must be singular;
  • Enum must have uppercase keys;
  • Enum must not be changed anywhere in the program.


This is how the solution using the Enum might look like:

We could keep using constants but it is much better and more correct to use structures that are better suited for this.

Also if we do the task with TypeScript, we can also change the type of user a little bit. This is many times better than using just strings.

Let's now imagine that a business comes to us and says that they want us to add a new type for the user's gender — 'non-binary'. We could do something like this:

But it looks very ugly. We could replace this with a switch statement, or a helper function that does it itself. This is a significant improvement, but we can also use special structures for this. We can use a Map data structure to make the solution more flexible and readable.


Map (dictionary, associative array, map) — a data structure that is used to map one value to another.

JS has a new Map constructor out of the box. The key difference from a common object is the ability to use any data type (even an object) as a key.

Usually, using the JS Map constructor is overkill. If you need the functionality that the JS Map provides, you have to use it. But usually a common object is used to imitate this structure.

There are some conventions how to configure this structure:

  • Maps must have a name by one of these patterns — xToY or xMap (userToPerson or userMap). The first pattern is used more often.


Here is how the solution might look like using the Map:

Have you noticed how we reused all the structures we have just learned about?

The choice of suitable data structures saved us from writing additional code. Using data structures and their combinations is a very powerful tool that is very much appreciated among developers.

Here are some more examples where using data structures helps a lot:

Select Control:



Here is an example of the getOptions helper:


TypeScript Enum

TypeScript has a keyword for the Enum's. The key difference from an object-enum is that with the TypeScript enum we can read values in two ways.

Cool! But I have almost never seen this used in production code. Therefore, I use and recommend that you use Enum in TypeScript in this way:

With const assertions we still use a regular object, but now it's on steroids.

Moreover, enum is always a reserved word in JavaScript, which means that maybe someday we will have a construct that the language itself will offer us.

Also, programs that compress the JS code cannot compress TS enum s. The same cannot be said about the objects that pure JavaScript offers us.

Enum TC39 proposals

As I said above, that Enum may appear in vanilla JavaScript someday. You can view the proposals that we have at the moment:

  • https://github.com/rwaldron/proposal-enum-definitions
  • https://github.com/rbuckton/proposal-enum
  • https://es.discourse.group/t/enumerations-syntactic-sugar/144

Usually, the solution that the language itself can offer is many times more effective than any third-party library can offer.

Do not forget to check the proposals that may appear in JavaScript language, and vote for the most interesting for you.


Data structures are awesome! They help us solve tasks in a neat and convenient way. With the right data structures, it's easier to build algorithms or not write code at all. The data structure may already be the solution to the task.

A huge plus is that if you do them according to the conventions that are present in the JavaScript language, most developers will understand your code much faster than coming up with something 'new.'

Most things are already invented for us!

Do not forget to put the constants of the same type into Enum s, then map them into the format you need, and enjoy the beauty of the data structures.