as enum assertion for object literals
#60790
Comments
RyanCavanaugh
added
Suggestion
|
This is a great idea! Symbol enums without
|
|
I worked on migrating my code using TS enums to be compatible with the In short, here is the code: const Foo: unique symbol = Symbol("Foo");
const Bar: unique symbol = Symbol("Bar");
const MyEnum = {
Foo,
Bar,
} as const;
type MyEnum = typeof MyEnum[keyof typeof MyEnum];
declare namespace MyEnum {
type Foo = typeof MyEnum.Foo;
type Bar = typeof MyEnum.Bar;
}
export {MyEnum};This is very close to the symbol enums discussed above, and would benefit a lot from an export const MyEnum = Object.freeze({
__proto__: null,
Foo: Symbol("Foo"),
Bar: Symbol("Bar"),
}) as enum;Or if R/T lands, the simpler: export const MyEnum = #{
Foo: Symbol("Foo"),
Bar: Symbol("Bar"),
} as enum;The reason why I use the particular expansion from my first code fragment is to keep nominal typing and have lightweight syntax in the type namespace.
I'm not sure if it would work. An important use case of enums is to act as tags for discriminated unions. For this, you don't need The way value and type namespaces interact in TS is a relatively advanced topic, so having |
|
Personally, I actually prefer enum-as-value and enum-as-type not diverging as much as they do with current enums. I never found that very intuitive. If you need
Given that As an aside, IINM, the following two lines should be equivalent: const Foo: unique symbol = Symbol("Foo");
const Foo = Symbol("Foo"); |
|
Should we be concerned about syntax that encourages/requires |
Using the accessor |
The problem that I see is that const foo = {
bar: Symbol("bar"),
} as const;In this snippet, This is why I proposed requiring |
🔍 Search Terms
enum, object literal, type-stripping
✅ Viability Checklist
Context
While TypeScript already allows declaring runtime enums values:
This is not standard JavaScript, and does not work in Node.js unless
--experimental-transform-typesis passed.An alternative "pure JS" pattern from the TypeScript handbook is:
https://www.typescriptlang.org/docs/handbook/enums.html#objects-vs-enums
There are two downsides to this pattern:
typeof X[keyof typeof X]is both verbose and not beginner friendly.⭐ Suggestion
Introduce some new syntax to TypeScript to help with the object-literal-as-enum pattern.
For example would be allowing
as enum:(from #59658)
An alternative design could be allowing an
enumtype annotation onconstvariable declarationsexport const Compass: enum = {...}.This annotation would effectively be the same as writing:
Rules
The
enumannotation would only be permitted for object literals that arei.e. the object literal would follow very similar rules that are applied to
const enum C {}syntaxBenefits
enumDownsides
While this object literal as enum pattern is popular in codebases that avoid non-standard runtime syntax it does not have all the features available with
enumsyntax such as self-reference during construction.__proto__: nullis currently not supported #38385 making it difficult to avoid object literals from inheriting non-enum properties resulting in false positives withkey in MyEnum.📃 Motivating Example
The above module will work out-of-the-box in Node.js (assuming nodejs/typescript#17).
💻 Use Cases
Creating an enum like value using standard Object literal syntax with some of the type system benefits that
enumsyntax has.typeof Foo[keyof typeof Foo]is not beginner friendly and is not a nominal typeOne workaround is to have a small utility for emulating an enum like nominal type from an object literal (playground). The
"literal" & { __key__: val }trick works but results in noisey types when displayed to the developer (e.g. in an error message)The text was updated successfully, but these errors were encountered: