Are you using enums to the fullest?

If it was not for enums you’d be writing code with literals everywhere.

Worse than that if you need to change a value, you’d do it at every place where you have used it. Of course with the current editors, it’s relatively fast but nothing comes even closer to changing a value at a single place and seeing its effect everywhere else. So honestly, there’s no reason to not using them already.

In this post, we will take the help of Javascript to explain how these variable input values in business logic could be managed faster and better in the Node.js environment.

The most common approach is to store the enum keys and values in a separate file, logically grouped together and usually frozen (constant) so that they don’t get accidentally overwritten.

enum.js

If you have been using enums like this, well done, you’re halfway there.

Wherever you need to set or check for user status, you can simply compare the value that is coming from outside of your code, such as a database call or an API request parameters. So far so good.

And suppose if you have to use enums collectively, such as during API request validation, you’ll probably use them like this,

validation.js

If you look closely, you will see that you are making your code less maintainable by spreading the items of the enum group. There are many places that you’ll use the enums collectively such as when designing a database schema, in the API validation, or inside the controller to check for an incoming value. This would become more evident if you are working in a micro-services architecture.

But where’s the problem you would ask, right?

Let’s imagine, now you have to add another post type, audio. In addition to increasing a new enum key in the, POST_TYPES now you have to update the key at every place and every service where you have used it. It’s so tiring just by thinking to add or change the enum, especially when we are in the initial stages of the development and this happens frequently as the requirements change.

Well, a simple and elegant solution for this is to let machines do the hard work. By creating the enum collection dynamically you get saved from the hassle of manually maintaining it everywhere else. Also, since this will be created at the bootstrap, you don’t have to worry about the runtime performance.

Follow along, Just create a file, preferably adjacent to the enum file (for easier maintenance), following the same hierarchy structure, and write the following code for dynamically generating enum collection

Notice how we are using the original enum to create an array from it. I have used Object.values here which simply extracts the RHS values from an object, but you get the idea from it, right? You have to get the values in a format that can be used in other places and almost every time it’s an array.

As you have the dynamically generated enum array, and now if you would need to add, remove, update keys in the original enum, this code will take care of it in every other place.

For example, to call it in your database schema, simple import enum_collection.js file as ENUM_ARRAY or by any other name you like, but it will get your job done, like a charm.

post_schema.js

And just by doing that, you’ll save a lot of time as your codebase grows.

Hope you like this little secret. Like and share if you found it useful.