DEV Community

loading...

Dealing with Enums in Vue.js

Kaique Garcia
Father of twins in the very beginning of life
・3 min read

Hello there.

Before I start, if you don't know what is or why you should be using Enumerations in any programming language, please read this nice article (specific for Javascript).

I know it's kind strange to see any concepts of Enums in anything made with Javascript 'cause everyone can deal with it based on freezed objects. That's really simple to do:

const MyEnum = Object.freeze({
  MY_KEY: "my_value",
});
Enter fullscreen mode Exit fullscreen mode

But everywhere I see some of these applications I found nobody is taking care about the structure of its code. You can easily found Enums declared inside other scripts. Why would you make such abstraction to use on the same place only? Is it an Enum or a group of constants? Whatever.

So I ended up trying some structures and that's what I liked most: Enum modules. I can show you an example based on a Vue.js 3 project.

So the obvious here is you have the project properly configured. There'll be the source folder (./src/) with all those other folders made to keep your code beautiful. Let's start.

1. Create a new folder for your future Enums

Just add this folder: ./src/enums/. As we're going to make modules, create a new folder ./src/enums/modules/ on it.

Remember: every Enum you want to create, put it in the modules folder.

2. Create your first Enum

For example, I'm going to add a new State Machine Enum focused on all possibilites to a random Post status:draft, scheduled, published.

So I'll create a file ./src/enums/modules/PostStatusEnum.js with this content:

const PostStatusEnum = Object.freeze({
  DRAFT: "draft",
  SCHEDULED: "scheduled",
  PUBLISHED: "published",
});

export default PostStatusEnum;
Enter fullscreen mode Exit fullscreen mode

Yeah, my first Enum :D

If you have a single Enum's project, that'll be all you need. 'Cause you will import it directly on any files you want to use it. For example:

import PostStatusEnum from "./../enums/modules/PostStatusEnum";

// code
Enter fullscreen mode Exit fullscreen mode

But that's not the right way to be prepared to the future. If you don't centralize your Enum modules you'll have to deal with a lot of import calls. In the future your code could be like:

import PostStatusEnum from "./../enums/modules/PostStatusEnum";
import OtherEnum from "./../enums/modules/OtherEnum";
import OneMoreEnum from "./../enums/modules/OneMoreEnum";
Enter fullscreen mode Exit fullscreen mode

Maybe it's working, but for sure it's not beautiful.

3. Organizing those modules

So let's centralize it adding a new file ./src/enums/index.js where we'll add any Enums to a huge package. Its content will looks like:

import PostStatusEnum from "./modules/PostStatusEnum";

export {
  PostStatusEnum as PostStatusEnum,
};
Enter fullscreen mode Exit fullscreen mode

And when you need to add more Enums to the list, you just need to add the import and export thing.

Ok, wait, what's the difference?

Let's go back to the "a lot of Enums" caos... Now you can call all the Enums you need from one import call:

import {
  PostStatusEnum,
  OtherEnum,
  OneMoreEnum
} from "./../enums";
Enter fullscreen mode Exit fullscreen mode

It's more legible. Even the path is smaller!
And this can be done with any other abstractions you want to do. For example, do you want to deal with Exceptions concept? You can do the same stuff, except any Exception will be a class extending the Error prototype.

What do you think? Let me know if you agree or not.

Cheers!

Discussion (0)