[girvo]

As others have pointed out, they're not really "strings" per se, or at least can be a lot stricter than a string might seem when used right. We use that constantly for useful things.

The bigger reason why it is this way is to ensure you can write type annotations for stringly-typed Javascript. While Typescript is it's own thing really at this point, it still is very focused on making it possible to type-annotate JS code.

    type Event = 'onClick' | 'onHover'

    // some stringly typed javascript can now be nicely typed
    something.triggerEvent('onClick', someData)

It lets you do some really nice things, and is quite strongly typed despite how it looks at first glace, while still letting me write some strongly-typed definitions for existing Javascript code that was very much __not__ written with types in mind.

[ygra]

In a similar case TypeScript even knows the signature of the event handler for addEventListener, and what type of Element document.createElement('div') returns. Someone even built typings for querySelector that parse the selector and returns the correct element type.

In general, however, I still think APIs written in TypeScript first are a lot cleaner type-wise than typings retrofitted onto a JS API. And having TypeScript as an afterthought these days doesn't seem like a good path to go anymore.

[girvo]

> In general, however, I still think APIs written in TypeScript first are a lot cleaner type-wise than typings retrofitted onto a JS API

Oh absolutely. Writing JS-first just seems like a lost cause. But there are still enough internal libraries and such written in very JS JS floating around that I come across at work that we need to interface with that I appreciate how much effort the TS team still puts into making sure I can drag those libs kicking and screaming into 2022.

[sanitycheck]

I found it interesting that I would never use strings this way in JS, but TS seems to encourage it. I definitely would not want to strip typing out of my TS code and try to maintain it as plain JS.

[xsmasher]

What would you use for a field called "stage" that could be set to 'dev' or 'stage' or 'prod'? Or other enum-type things?

I've seen pure JS enums like {'dev' : Symbol('dev'), 'prod' : etc} but I never use them because you can't send them over the wire.

You could use a type like {dev:true} | {prod:true} | {stage:true} but you still wind up comparing strings.

[mmis1000]

> {dev:true} | {prod:true} | {stage:true}

This can't be accessed safely. Because all value in typescript can be sub type of how it typed.

It means code following will pass.

    var a = { dev: true, get prod() { throw Error() } }
    var b: { dev:true } | {prod:true} | {stage:true} = a

And there is no guarantee that access any of these fields is safe.

[xsmasher]

That did not compile for me with my TS settings;

> Type '{ dev: boolean; readonly prod: void; }' is not assignable to type '{ prod: true; }'

It's still a bad solution though; it allows nonsense values like {dev:true, prod:true}.

[mmis1000]

That is because I forgot to assert the true as literal true, so it defaults to be boolean (where both true and false are allowed)