But then I find some third party code which seems to use the kitchen sink approach to typing, AKA the "look at how smart we are" approach, and it's a nightmare to understand. A type system is supposed to make code easier to work with, by the time you're spending more time understanding the types than the actual code there's something wrong.
In these cases I wish Typescript was more limited and I would gladly give up a lot of the new stuff to enforce simple types across the ecosystem.
That said, I don't really have an opinion on who is at fault here - coders for writing overly elaborate types, or Typescript for allowing them.
Example the new satisfies and some upcomign "as const" features to generics I'm looking forward to
Backwards compatibility is to blame. Typescript was designed to support a number of patterns which was already used in JavaScript.
For example events are registered in the DOM like `element.addEventListener("click", (ev) => ...)`. The type of the callback will depend on the string passed as the first argument, so the type system need to support literal strings as type discriminators which is a weird feature not necessary in most other languages. If the API had been designed with static typing in mind from the beginning, it would have been designed differently and wouldn't need such a complex type system.
foo(get_some_myenum_value(), …)
{type:get_another(), …}
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.
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.
type Shape = Square Int | Circle Int
print (Square size) = ..
print (Circle radius) = ...
type Shape = { type: 'square', size: number } | { type: 'circle', radius: number }
function print(shape: Shape) {
if (shape.type === 'square) {
...
} else if (shape.type === 'square) {
...
}
}
It also have some pitfalls, e.g. you can write:
print({type: 'square', size: 10});
const x = {type: 'square', size: 10};
print(x); <-- type error
const x = {type: 'square' as const, size: 10};
print(x);
Now take mapped types, template literal types, key remapping... Those features aren't necessary to express legacy DOM APIs, this is just for the sake of having a complex typing system. And that's not to add a new feature that unlocks some type magic that wasn't possible before. No, those are just shorthands for things that you could already express in the existing typing system.
For example the 'options' parameter is a common pattern where an object with a set of properties are provided to override a some default behavior. So you need to define a Foo type with a set of properties, and then you need to define a type which is like Foo except all properties are optional.
Some frameworks implement their own flavor of inheritance e.g. through mixins. The type of an object with mixins is not just the sum of all properties, you might also have one property overriding a property of a different type in base mixin, so you are adding and removing properties. You need a really powerful type system to be able to represent this.
This may be true in a lot of cases, but certainly not all.
I’ve spent a ton of time on the types that validate that the input/output schema of my request handler function matches the defined schemas, and that was hell, but now any other of our developers will see delightfully red squiggles when they do something wrong. That’s a force multiplier and absolutely worth the effort.
Also try exploring npm/telegraf classes (auto-documented) by looking at their type definitions. The whole bot api could have been written as simple repeated definitions, but someone chose the clever way of multi-level type mutations and derivatives.
Typescript will soon need secondary community-maintained type contracts that are human-readable and cross-checked with those in libraries. Something like @humane-types/*.