Michael Kim

⚔️ Are Enums Really Harmful?

Today I had a discussion with some friends at Theodo about Matt Pocock’s video dramatically titled “Enums considered harmful”. The video expresses Matt’s views about how Typescript native enums are a big no-no and should essentially be avoided and discouraged.

I’m a big fan of the way Matt breaks down concepts and explains them clearly, BUT - there was clearly much to debate, with viewers expressing different opinions in the comment section. And so we sat down for 30 minutes to put an end to the question - have we been lied to, and are typescript Enums actually dangerous to use??

👆 Points Raised in Video

💡

Here’s a quick analysis of Matt’s points from the video to start (points are simplified)

Typescript native enums look a bit like this

TS enums are transpiled to Javascript objects in an unintuitive way - they eventually look like this

So doing normal JS object manipulation can be annoying - for example, mapping over the keys of an enum, which in my opinion is a fairly common operation

How can we avoid this? One way is by using POJOs, or plain old javascript objects that look like this

The added const assertion just ensures the enum members are readonly

This is defined as a javascript object, and so no weird transpiling issues occur

💭 Michael’s Opinion:

So “POJO” enums seem to get around the object transpiling issue - why not just use these JS “enums” all the time?

There is one major drawback - they allow for the usage of the enum’s primitive values directly in code (such as 'apple' above), instead of throwing type errors and demanding something like FruitEnumPojo.Apple

Matt’s opinion on this is clearly stated in the video - since Typescript is technically a “structural” type system and not a “nominal” type system, this is exactly what we should expect, and how we should interact with our code. Structural type systems should not care about names, but only runtime values.

Structural type systems should be ok with using the enum values interchangeably with explicit references to the values through the enum keys like in the snippet above, and this makes for a more intuitive developer experience.

💥

This is where I disagree! (Somewhat)

In my opinion, such interchangeable use of "apple" and FruitEnum.Apple encourages the use of “magic” values without a reference, and thus

Makes refactoring harder as there is no single source of truth, and each instance of "apple" must be modified if the enum member’s value ever changes

May slightly reduce the readability of your code, because seeing test("apple") in your code raises many questions, such as: is “apple” definitely a valid argument? (A new developer may need to check that it is typed correctly and that the primitive values passed to test are permitted)

⚖️ So, What is the happy middle?

My personal choice of enum are typescript string enums that look something like this

The usage of string enums in my opinions avoids all of the pitfalls that Matt references. The transpiled JS is intuitive and as expected, matching the output of the JS enum with const assertion (see below)

We also can be stricter about accessing enum members explicitly rather than magic values in code, with type errors being thrown otherwise.

📕 Closing Thoughts

The tradeoffs between string enums and Matt’s proposed POJO enums are centred around readability, maintainability and object manipulation, and can be seen below:

ㅤ	Readability	Maintainability	Object Manipulation
Typescript String Enums	🟢	🟢	🟢
POJO Enums	🟡 Magical values raise questions about type safety, slightly impacting readability	🔴 No single source of truth for enum member values makes refactoring harder	🟢

Overall, while Matt provides an interesting viewpoint on the use of Typescript enums, I am not entirely convinced. I believe string enums mitigate most of the drawbacks that Matt raises, and the drawbacks of their usage do not outweigh the benefits.

To his credit, Matt does give some leeway to typescript enums, saying while he wouldn’t actively encourage them he wouldn’t reject any pull requests based on their usage - and it should be noted that much of the conclusions above are to some extent down to developer preference. Matt may feel that the coercion of typescript into a nominal type system is far too jarring and that it produces a very negative and unintuitive developer experience.

And importantly, setting the standard of using string enums opens the doors for the risk of new or less experienced developers joining a project to accidentally use variants such as numeric and non-string typescript enums, which have a much more negative impact (such as the weird object transpiling issue we discussed earlier).

Therefore for each project, I would advise you take into consideration the experience level of the developers in conjunction with the benefits / risks tradeoffs discussed and come to an informed decision, with my personal preference in most cases being string enums.

If you disagree or have any further comments or questions about my opinions, please don’t hesitate to contact me directly - I would be happy to fill any personal knowledge gaps 🙂