TypeScript is well-loved by the developer community for many reasons, one of which is because of the static checks it provides to the code written in it.
Spotting problems early in your development lifecycle can save days of debugging random, vague errors that can sometimes pop up when using dynamic languages like JavaScript.
TypeScript can help make your code more predictable and better documented, make refactoring easier, and help reduce potential errors you might face at runtime in your production app. Its popularity and power are demonstrated by its 93% developer satisfaction rate and its skyrocketing usage over the past five years.
One language mechanism that is pivotal to TypeScript is enums. In this article, we’ll discuss:
Enums aren’t a feature of typing, interestingly, like most of TypeScript is — in fact, they are one of the few, new features that enhance the language.
Enums allow developers to define a strict set of options for a variable. For example:
enum Door {
Open,
Closed,
Ajar // half open, half closed
}
Enums default to number enums, so the above enum is essentially an object with 0, 1, and 2 as its key, which we can see in the transpiled JavaScript code.
"use strict";
var Door;
(function (Door) {
Door[Door["Open"] = 0] = "Open";
Door[Door["Closed"] = 1] = "Closed";
Door[Door["Ajar"] = 2] = "Ajar"; // half open, half closed
})(Door || (Door = {}));
console.log(Door.FullyOpened);
In TypeScript, you can also use string enums, like so:
enum Door {
Open = "open",
Closed = "closed",
Ajar = "ajar" // half open, half closed
}
If you then used this Door enum, you could ensure that variables only used the three options specified in the enum. So, you couldn’t assign something incorrectly by accident or easily create bugs this way.
If you do try to use another variable, it will throw a type error like this:
enum Door {
Open = "open",
Closed = "closed",
Ajar = "ajar" // half open, half closed
}
console.log(Door.FulyOpened)
Property 'FullyOpened' does not exist on type 'typeof Door'.
Extension is one of the four pillars of object orientation and is a language feature present in TypeScript. Extending an enum allows you to essentially copy a variable definition and add something extra to it.
So, for example, you might be trying to do something like this:
enum Door {
Open = "open",
Closed = "closed",
Ajar = "ajar" // half open, half closed
}
enum DoorFrame extends Door { // This will not work!
Missing = "noDoor"
}
console.log(DoorFrame.Missing)
We could then add extra properties into an enum, or even merge two enums together, to still get strict typing on our enum while also being able to change them after they’ve been defined.
But notice that the above code snippet doesn’t work! It fails to transpile and throws four different errors.
The short answer is no, you can’t extend enums because TypeScript offers no language feature to extend them. However, there are workarounds you can utilize to achieve what inheritance would.
enum Door {
Open = "open",
Closed = "closed",
Ajar = "ajar" // half open, half closed
}
enum DoorFrame {
Missing = "noDoor"
}
type DoorState = Door | DoorFrame;
let door: DoorState;
door = Door.Ajar
console.log(door) // 'ajar'
door = DoorFrame.Missing
console.log(door) // 'noDoor'
In the above code block, we used a union type. The union acts like an “or,” which simply means that the DoorState type will either be of type Door or of type DoorFrame.
This now means DoorState can use either of the variables from the two enums interchangeably.
However, an important caveat is that it can only use the types of the two enums. In TypeScript, it isn’t possible to use the values, like ajar and noDoor. You need to use the types like DoorFrame.Missing, which is a limitation.
We have seen in the transpiled code earlier that an enum becomes a JavaScript object, with the keys and values that your enum specifies.
In TypeScript, we could write purely JavaScript if we wanted to. In fact, this is one big strength of TypeScript. You could, for example, rename all your file.js to file.ts and turn off the compiler checks for your code. As long as you run the compile/transpile steps, everything would work fine, with zero code changes.
We can make use of this by knowing that when our enum turns into JavaScript, it will be a JavaScript object literal and use the spread syntax, like below:
Learn more →enum Move {
LEFT = 'Left',
RIGHT = 'Right',
FORWARD = 'Forward',
BACKWARD = 'Backward'
}
const myMove = {
...Move,
JUMP: 'Jump'
}
This solution has been described secondly, though, as it isn’t as good of a solution as the union type because it isn’t as robust as our first solution. This is because the “composition” of your enum is occurring at run time, whereas when we use type union, type checking can occur at compile/transpile time, not runtime.
We have discussed how we can extend enums in Typescript, but enums aren’t a magic bullet to be used to fix all problems. Enums, when used incorrectly, can make your code readability, scalability, and maintainability worse, rather than improve your code.
So, let’s cover some best practices and common patterns to use when working with enums in TypeScript.
I have explained how we can have string enums like this:
enum Seasons {
Summer = "Summer",
Winter = "Winter",
Spring = "Spring",
Fall = "Fall"
}
Alongside also having numerical enums like this:
enum Decision {
Yes,
No
}
But, there is a third type of enum, which you may not be aware of, called a heterogenous enum. This is where you can use a string and numerical enums in the same enum.
An example from the docs is this:
enum BooleanLikeHeterogeneousEnum {
No = 0,
Yes = "YES",
}
It’s important to note that even the docs discourage this practice, as in this instance, using this method indicates you likely need to:
Sometimes code functionality can be forced to adhere to an enum option, which can quickly turn into an antipattern.
Here’s an example:
enum Operators {
Add,
Subtract
}
function calculate(op: Operators, firstNumber: number, secondNumber: number) {
switch(op) {
case Operators.Add: return firstNumber + secondNumber
case Operators.Subtract: return firstNumber - secondNumber
}
}
The above code looks fairly simple and safe, because our example is, indeed, simple and safe.
But in large codebases, when you strictly tie implementation details to enum types like this, you can cause a few issues:
If you need to do something like the above, a simpler (and more condensed) pattern could look like this.
const Operators = {
Add: {
id: 0,
apply(firstNumber: number, secondNumber: number) { return firstNumber + secondNumber }
},
Subtract: {
id: 1,
apply(firstNumber: number, secondNumber: number) { return firstNumber - secondNumber }
}
}
You can read more about this pattern here or here.
There is a way of generally grouping together different types of data utilized in code: discrete variables or continuous variables.
Discrete variables are data that have spaces between their representations, and have only a few representations. Here are a few examples:
Discrete data is a good candidate to be placed inside an enum, and it can help code clarity and reuse. Continuous data refers to data without gaps that fall into a continuous sequence, like numbers. These can be different depending on their measurement:
Discrete data is a good candidate for data, and it can be used in an enum, whereas continuous data should not be used in an enum. Can you imagine an enum for age?
enum Age {
Zero,
One,
Two,
Three,
Four,
Five,
Six
}
This is not a good candidate to be placed in an enum because it will need to be continuously updated and amended, leading to a maintenance nightmare.
You should only look to add discrete, highly stable types of data inside an enum.
I hope this article has been useful so you better understand what enums are, the problems they solve, the use cases for merging two enums, and how you might achieve it! Happy hacking.
LogRocket is a frontend application monitoring solution that lets you replay problems as if they happened in your own browser. Instead of guessing why errors happen or asking users for screenshots and log dumps, LogRocket lets you replay the session to quickly understand what went wrong. It works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store.
In addition to logging Redux actions and state, LogRocket records console logs, JavaScript errors, stacktraces, network requests/responses with headers + bodies, browser metadata, and custom logs. It also instruments the DOM to record the HTML and CSS on the page, recreating pixel-perfect videos of even the most complex single-page and mobile apps.
Would you be interested in joining LogRocket's developer community?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Get to know RxJS features, benefits, and more to help you understand what it is, how it works, and why you should use it.
Explore how to effectively break down a monolithic application into microservices using feature flags and Flagsmith.
Native dialog and popover elements have their own well-defined roles in modern-day frontend web development. Dialog elements are known to […]
LlamaIndex provides tools for ingesting, processing, and implementing complex query workflows that combine data access with LLM prompting.
One Reply to "How to extend enums in TypeScript"
>In the above code block, we used an intersection type. The intersection acts like an “or,” which simply means that the DoorState type will either be of type Door or of type DoorFrame.
Isn’t that a union type? Although, the resultant type will let code only compile if the type is used such that only properties in the *intersection* of the types being unioned is accessed.