3 ms·
The event type could just be exposed as a regular property so you could write `element.onclick.add((ev => ...)` so you would get static typing without any need
by goto11 4y ago
The event type could just be exposed as a regular property so you could write `element.onclick.add((ev => ...)` so you would get static typing without any need for magic strings.
Magic string are use all over JavaScript for different purposes. For example createElement('P') could just be new PHtmlElement() ...
In other cases magic strings could be replaced with enums.
- madeofpalk 4y agoChanging Javascript is explicitly out of scope for Typescript. I was curious how other languages did discriminators in a way that makes Typescript's feel alien. Just having different functions doesn't really tackle that.
- deleted 4y ago[deleted]
- goto11 4y agoThe pattern I'm most familiar with is using type constructors: type Shape = Square Int | Circle Int and then pattern matching: print (Square size) = .. print (Circle radius) = ... In Typescript this would be something like: type Shape = { type: 'square', size: number } | { type: 'circle', radius: number } And string matching for type narrowing: function print(shape: Shape) { if (shape.type === 'square) { ... } else if (shape.type === 'square) { ... } } The TypeScript approach is comparatively weird and verbose but also pretty clever since it doesn't require any change to the core language. It also have some pitfalls, e.g. you can write: print({type: 'square', size: 10}); But you cant write: const x = {type: 'square', size: 10}; print(x); <-- type error You have to write: const x = {type: 'square' as const, size: 10}; print(x); Things like this just complicates the type system and type inference.