Typescript: Feature request: Decorators on enum members

[billccn]

It would be nice to be able to decorate enum members (in the same way as properties?).

[igabesz]

Indeed, it could save lots of copy-paste code, e.g. when making string <--> enum conversions which is a strong industrial case.

Now I do this a lot:

enum AnimalType { 
  Cat, 
  Dog,
  Invalid
}
module AnimalType {
  export function parse(str:string):AnimalType {
    switch(type) {
      case 'cat': return AnimalType.Cat;
      case 'dog': return AnimalType.Dog;
      default: return AnimalType.Invalid;
    }
  }
  export function toString(type: AnimalType): string { /* ... */ }
}

How nice would this be:

enum AnimalType {
  @parse('cat')
  Cat, 
  @parse('dog')
  Dog,
  @parseDefault('invalid') /* parses everything, toString returns 'invalid' */
  Invalid
}

[mhegazy]

@igabesz can you explain how parse would be implemented? what does it return?

[igabesz]

I'm thinking of something like the C# DisplayName annotation. The main point is that @parse stores the string given to it; this string can be retrieved somehow through some metadata. The rest of the string-to-enum mapping should be implemented in a given function, but only once, not once per enum type.

I'm not very familiar with the current annotation syntax (btw any good and deep tutorials?), but I imagine something like this.

var AnimalType = (function(AnimalType) {
  AnimalType = {
    Cat = 0,
    Dog = 1
  }
  // this is some annotation or decorator container
  Object.defineProperty(AnimalType, '__decorators', {
    enumerable: false,
    configurable: false,
    writable: true,
    value: {} // or maybe a Set?  
  });
  // Something like this should be auto-generated
  // Can be in a different format, e.g. AnimalType and value could be passed too
  AnimalType.__decorators[AnimalType.Dog] = [ new parse('dog') ];
  AnimalType.__decorators[AnimalType.Cat] = [ new parse('cat') ];
  return AnimalType; 
}) (AnimalType || {});

// Defining annotation (just the relevant part)
function parse(str) {
  this.__annotationName = 'parse';
  this.str = str;
}

// One must implement these two functions by hand
// But they are general so they can be used with any enums 
function printEnum(enumType, value) {
  var annotations = enumType.__decorators[value];
  var parseAnnotation = getParseFromList(annotations);
  return parseAnnotation.str; 
}
function readToEnum(enumType, str) {
  var decorators = enumType.__decorators; 
  var value = selectEnumValueWhereTheParseAnnotationMatches(str); 
  return value; 
}

[mhegazy]

This is significantly different behavior from what decorators mean for classes. this means that you can not take your knowledge of writing a class /ES7 decorator to enums.

[ghost]

+1

[niemyjski]

+1

[danilobjr]

+1

[ss108]

+1 to being able to decorate enum properties just like the props of any other object

[sevensc]

+1

[rk-7]

👍 We definitely need decorators for enum members.

[b3ross]

Any update on this?

[kbalint]

+1

[mmeasor]

+1

[KrakerXyz]

+1

[admin-fsoft]

+1

[igabesz]

Currently TypeScript implements an older and now obsolete version of the ES Decorator proposal. The TypeScript Roadmap mentions the implementation of the new syntax, however it is not scheduled yet. (Well, it seems to be a huge pain with lots of coordination and breaking changes.)

I guess if there is any progress then it should be according to the new decorator syntax for classes -- as much as it can be applied on enums. Any official word on this?

[carsoni]

Definitely required

[winuxue]

any update?

[alannsiqueira]

+1

[activebiz]

+1 Would be great feature.

[spyter]

+1

[shellscape]

Let's keep this one at the forefront.

[orta]

Until the JS standard body has made some concrete decisions on what decorators should look and act like, we're unlikely to be adding new decorator features to TypeScript. Please don't add +1 comments unless you have something new to add.

[cztomsik]

There's a new, simpler proposal (again at stage2) for decorators - since when will you consider adding new features like this one? It could save us some boilerplate with graphql enum registering (but we'd need to somehow get the enum name).