vega-typings enum discussion

Hi everyone, I’d like to start a discussion about the possibility of using enums in vega-typings.

There are quite a few types that are union types of a bunch of string constants. Examples: https://github.com/vega/vega/blob/master/packages/vega-typings/types/spec/marktype.d.ts https://github.com/vega/vega/blob/8941b87cbfd678618d76b6e0a99aa5f77c43abc3/packages/vega-typings/types/spec/scale.d.ts#L4

There are also some that almost conform to this pattern, but have additional members like SignalRefs.

For example: https://github.com/vega/vega/blob/8941b87cbfd678618d76b6e0a99aa5f77c43abc3/packages/vega-typings/types/spec/scale.d.ts#L29

This SortOrder example makes me think that we should switch to enum types for this use case, because in working on Lyra I noticed that if we adopt vega-typings, we currently have to either 1) use raw string literals or 2) keep a separate struct in Lyra to store the literal values. These will both easily go out of sync with vega-typings (they already have, because the SortOrder constants changed from asc to ascending and desc to descending between Vega 2 and today).

The benefit of using enum: they provide the type and the values at once. So, you could define an enum SortOrderValues and use SortOrderValues.Asc without worrying about the underlying constant, and you can also type variables as x: SortOrderValues to get the behavior we already have with union types.

tl;dr what if we e.g. replaced SortOrder with something like

export enum SortOrderValues {
  Asc = 'ascending',
  Desc = 'descending'
}

export type SortOrder = SortOrderValues | SignalRef;

[domoritz]

Should we close this issue for now?

[kanitw]

Oh right, I wonder if the same approach works with the transformer.