Changelog:
- 6 Nov 2019: Added
type
for better developer experience.
I know we can use typescript's enum
, but, the difficulty arises when I'm receiving string in REST, and want to validate the property value in the request.
This is the way I write my enums:
// ===== DECLARATION =====
type TerrainEnum = 'MEADOW' | 'OCEAN' | 'FOREST';
class Terrain {
public static readonly Meadow = 'MEADOW';
public static readonly Ocean = 'OCEAN';
public static readonly Forest = 'FOREST';
public static isValid = (value: string): boolean => (
value === Terrain.Meadow ||
value === Terrain.Ocean ||
value === Terrain.Forest
);
}
// ===== USAGE =====
// Validate
Terrain.isValid(value);
// In function parameter
const myFunction = (terrain: TerrainEnum): void => {}
I think this way you have a built-in input validations, simply by calling isValid()
.
I'm interested in what you guys think. Maybe we can find any better option out there.
So, what's your preferred way to write enums? And what's the reason behind yours?
Top comments (8)
How about creating a "Value Object" (often used in DDD).
Hello, thanks for your answer. By the way I never heard of DDD yet. Care to elaborate? :)
Here's a link to the definition of Domain Driven Design (DDD)
"Domain-driven design is predicated on the following goals:
And here's an implementation of Value Objects in Typescript
How about using typescriptlang.org/docs/handbook/e...
in that case, you can set in the constructor that you expect TerrainEnum value e.g.
Hi thanks for your answer. I think I prefer to define it in 1 class only. Any other alternatives? :)
What do you think about this code:
What happens if we omit
<any>
? Isn't it should infer any by default?I personally, prefers to write it in 1. Splitting into 1 enum and 1 class seems weird.
One of the problem is when we try to deserialize string to enum.
E.g. when getting string from rest call. When this happens, I think we should make our parameter as
Terrain | string
anyway right?If you remove any you will get an error. Actually any should be avoided.
Alternative solution is:
But it works in >= ES7. Keep in mind that key and value in this enum must be the same, for example OCEAN = "OCEAN"
I find enum/class much cleaner that creating many static const in the class. Why do you find it weird?
It's completely fine to extract possible values to an enum/object/array/dictionary:
First if I had to add a new option adding it to an enum would be much cleaner than modifying the class and having for example 10 static constants in the class + modifying IF condition.
Secondly maybe other parts of your application will use this enum if your project starts to grow. In this case I would even consider to put this enum into a separate file. All parts would import the enum and would not depend on the Terrain class.
when getting string from rest call...
I think you always get a string (or number or null) from the rest call.
You can create an enum var like that: