TypeScript Enums vs. Flow Enums(medium.com)
medium.com
TypeScript Enums vs. Flow Enums
https://medium.com/flow-type/typescript-enums-vs-flow-enums-83da2ca4a9b4
8 comments
This is a significant improvement on Typescript’s enums but I wonder what the underlying code it compiles to is.
Because we’re planning on moving our codebase to ESM support (the community is moving over quickly), we’ve run into a number of issues with TS enums, the primary one being that TS enums compile to undefined vars that are populated with an IIFE, which disallows using them in certain import/export situations.
Because we’re planning on moving our codebase to ESM support (the community is moving over quickly), we’ve run into a number of issues with TS enums, the primary one being that TS enums compile to undefined vars that are populated with an IIFE, which disallows using them in certain import/export situations.
Here are the docs for exporting/importing enums: https://flow.org/en/docs/enums/using-enums/#toc-exporting-en... - works fine with the new export/import syntax.
Docs for enums compilation/runtime are here: https://flow.org/en/docs/enums/defining-enums/#toc-enums-at-...
Docs for enums compilation/runtime are here: https://flow.org/en/docs/enums/defining-enums/#toc-enums-at-...
That's very cool, thank you so much.
My recommendation is to not use enums; use plain string unions instead. There's no wondering about how they compile or serialize (or deserialize), there's no importing/exporting (except the types), you even get autocomplete. And TypeScript makes them every bit as safe as enums (more so, based on some things I learned in this article).
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.
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.
That is an annoying thing I've run into as well
My solution is to make a type guard:
(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)
My solution is to make a type guard:
function isExample(val: string): val is Example {
return (ALL as string[]).includes(val)
}
(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)
Oh that’s very clever. Makes me wish javascript/Typescript had macros so I could define this all in a single call.
Some of them can worked around by structuring your code in certain ways (for example you could make sure every variant is covered by indexing into an object with `key in MyEnum`, or by returning from each switch case and requiring a particular return type)
But even setting those aside, I got burned so badly the last time I used Flow that I'm not sure anything could convince me to return to it