Enums instead of union types.

[nilss0n]

First of all, thanks for the very helpful library.

One thing I've noticed is that the union types used for parameter values etc are a bit cumbersome when writing and navigating code. I think it would be easier to use enums. For example, if we take the following type:

type GPUVertexStepMode =
  | "vertex"
  | "instance";

We could also define it like:

enum GPUVertexStepMode {
    VERTEX = "vertex",
    INSTANCE = "instance",
}

At the usage site, we get:

const bufferLayout: GPUVertexBufferLayout = {
    stepMode: 'vertex', // With type unions
    stepMode: GPUVertexStepMode.VERTEX, // With an enum
};

I think there are two benefits of using enums, one is that you can type EnumName. to see the available options. The other benefit is that you see the name of the type at the usage site, if I only see "vertex" I have to look up the struct or function type to see the definition.

Is there any reason not to use enums that I've missed? If not, is it something you think belongs in this library?

Thanks in advance,
Martin

[kainino0x]

An enum wouldn't accurately reflect what the browser actually exposes:

stepMode: GPUVertexStepMode.VERTEX, // With an enum

The JavaScript GPUVertexStepMode.VERTEX wouldn't work in a browser because GPUVertexStepMode doesn't exist - the WebIDL definition for GPUVertexStepMode doesn't expose anything to JS, it only affects the bindings semantics.

[nilss0n]

Right, I realised that you probably won't publish any code, just types. So I guess it makes more sense to set up that kind of enum or other helper types in my user code or libraries etc. Thanks for the clarification.