0

The Typescript handbook hasn't really given me much information on how to correctly use the string enums.
Here is my example:

enum ICE_CREAM {
    strawberry = "STRAWBERRY",
    vanilla = "VANILLA"
}

type TORDER = {
    greetings: string,
    flavor: ICE_CREAM
}

const mockData: TORDER = {
    greetings: "Hello",
    flavor: "VANILLA",
}

which leads to the error Type

'"VANILLA"' is not assignable to type 'ICE_CREAM'.(2322)

My backend will send data which contains the "flavor" key and I want to make sure that its value is one of the values declared in my ICE_CREAM string enum. What am I doing wrong?

1
  • Typescript's type checking is not going to work on runtime data from the backend anyway (by the time the program is running, it's all compiled to javascript), you would need to have a separate runtime type guard for that. Commented Jan 19, 2024 at 22:01

2 Answers 2

3

It is by design that you cannot assign a string to a property who's type is an enum. You must refer to the enum in order to assign one of its values.

flavor: ICE_CREAM.vanilla

However, there is a better way to go by using string union types. This way you keep your types strong, while letting your strings be strings.

type ICE_CREAM = 'STRAWBERRY' | 'VANILLA';

type TORDER = {
    greetings: string,
    flavor: ICE_CREAM
}

const mockData: TORDER = {
    greetings: "Hello",
    flavor: "VANILLA", // Assigns without error
}

const badMockData: TORDER = {
  greetings: "Hello",
  flavor: "vanilla", // Error: flavor can only be 'STRAWBERRY' or 'VANILLA'
}
Sign up to request clarification or add additional context in comments.

1 Comment

ah, thank you. So for my use-case, string union types indeed are the correct approach and enums do not even fit my need. Nice!
1

Intuitively it seems like you should be able to use the underlying string because after all they are the same right?

However, semantically they are not the same. Take this enum for example:

enum SILLY_PROGRAMMER {
    ten = "TEN",
    twenty = "TWENTY"
}

Say some programmer had used this enum around their 1000s of lines of code when suddenly they realize they made a mistake! Their original code was actually this:

enum SILLY_PROGRAMMER {
    ten = "TWENTY",
    twenty = "TEN"
}

Oh no! Now they will have to rewrite everything, right? Wrong, they just have to change the enum. This is especially useful when you are writing APIs and have some error in constant data you are returning, just change the enum.

Without this, however, rather than it automatically being updated, the types just mismatch. This means you have to go and manually correct it wherever you see the error.

Thus this is why this decision was made and why it is the "correct" decision to make if you want to have the above behavior.

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.