|
|
|
|
|
by NoahTheDuke
1733 days ago
|
|
That's what we had to do. We now define our "enums" as a `const` object: `export const Example = { First: "first", Second: "second", ... } as const;` and then define the type immediately following: `export type Example = (typeof Example)[keyof typeof Example];` which lets us change the const object without having to also change the type. The only downside so far is that `[Example.First, Example.Second].includes(user.example)` no longer works because the array's type is narrowed to the tuple `("first", "second")` instead of an array of Examples `Example[]` without casting: `([Example.First, Example.Second] as Example[]).includes(user.example)` or worse `[Example.First, Example.Second].includes(user.example as any)`. Because this is an extremely common pattern for us, we've taken to using the lodash function `includes` which is typed differently but performs the exact same check under the hood. |
|
My solution is to make a type guard:
I've also found there's no need to even create an object by the way; you can just create a string array and then use string literals directly in your code. Also, TS is smart enough to still give you intelligent autocomplete.(you don't even need the array unless you need to iterate over the items at runtime like above; in other situations, you can often just make a type and nothing else)