Earlier quoted context omitted.
Honestly I find this question crazy. Have you never made an asynchronous data call returning an array of objects with properties that are complex types? You're already at Promise >. What if you have to keep track of multiple of those calls at once in a data structure? Have you never used map or filter operations on streams of data? Do you really think functions returning functions is "really really complicated"? It m…
> Have you never used map or filter operations on streams of data? If that's the standard for complicated programs, then I really don't understand how types can get confusing; filter doesn't even change the types of its arguments. I guess structs of several promises are a good example because you could mix up which fields contained which future objects, and that code would be distant from the API call to produce the…
But map, which 90% is used after filter, does.
const foo = client.someRequest()
.filter(item => /* some condition */)
.map(item => /* some transformation */)
someFunction(foo)
The answer is either:
- you implement your own type system (based on json schema?)
- you write the type checks manually in your tests
Every REST/GraphQL APIs relies on a strongly typed schema.
A type system in your programming language is a feature that allows you to "encode" the schema within the language itself.
The most expressive the type system is, the less validation code you need. The less code you have, the easier it is to maintain your code.
You don't like the verbosity? That's what type inference is for, take a look at that Typescript example:
const handlers = {
foo: () => { /* ... */ },
bar: () => { /* ... */ }
}
const action: keyof typeof handlers = someOtherFunc()
handlers[action]()