Add memberNames attr identifier to enhance kind="enum"

[sdboyer]

By default, kind="enum" uses a CamelCasing-ish strategy on values to decide on member names to correspond to those values. This is a nice default, but it doesn't help when the values of the disjunct are numerics instead of strings, or if the user just plain wants some other pattern.

For that, we need cuetsy to support another attribute identifier. What i did here should work fine - a memberNames attr identifier, which expects a |-delimited list of strings, equal in count to the number of elements in the disjunction. memberNames will be required if the disjunction contains any numeric values.

CUE

TS

package cuetsy // Enum-level comment // Foo: member-level comment // Bar: member-level comment AutoCamel: "foo" | "bar" @cuetsy(kind="enum") // Enum-level comment // Foo: member-level comment // Bar: member-level comment ManualCamel: "foo" | "bar" @cuetsy(kind="enum",memberNames="Foo|Bar") Arbitrary: "foo" | "bar" @cuetsy(kind="enum",memberNames="Zip|Zap") Numeric: 0 | 1 | 2 @cuetsy(kind="enum",memberNames="Zero|One|Two") ErrMismatchLen: "a" | "b" | "c" @cuetsy(kind="enum",memberNames="a|b") ErrNamelessNumerics: 0 | 1 | 2 @cuetsy(kind="enum")

/** * Enum-level comment **/ enum AutoCamel { // member-level comment Foo = "foo", // member-level comment Bar = "bar", } /** * Enum-level comment **/ enum ManualCamel { // member-level comment Foo = "foo", // member-level comment Bar = "bar", } enum Arbitrary { Zip = "foo", Zap = "bar", } enum Numeric { Zero = 0, One = 1, Two = 2, }

[sdboyer]

@ying-jeanne this might be more straightforward to work on than trying to dynamically inject the cuetsy attributes

[sdboyer]

@ryantxu asked about comments over in #14. i've updated the OP accordingly.

[ryantxu]

// TS authors: "you can do this, but it's probably silly, maybe don't?"
Heterogeneous: 0 | 1 | "foo" @cuetsy(kind="enum",memberNames="Zero|One|Foo")

Lets not promote that one :)

The "number" case is an artifact of defining an enum directly -- it translates to numbers, but I think is something we should avoid generally. (and need good ways to map from numbers to strings in migrations)

[sdboyer]

Fair enough, removed the heterogeneous case :) It'll still be supported, necessarily, but no need to promote it.

Is the concern about numeric enums specific to what we want to define as best practices in Grafana, or does it extend to TS more widely?

[ying-jeanne]

@sdboyer Make sense, I could take over this request, I don't have right to assign myself to the issue somehow :).

[sdboyer]

@ying-jeanne assigned! will add you to repo, too