So I've been working though with TypeScript over the last 2 weeks or so, converting a pet project from JS to TS.
Aside from a few management issues (to be expected!) my experience has been amazing.
As a guy with C# experience, being able to clearly create my function overloads is amazing, I love it, and once Generics make it in, it'll be even better. Being to have the type checking go into the function from the compiler level is great.
One thing that would be nice to have, is potentially the ability to define multiple possible return values.
From the compiler point of view, you couldn't infer the real return type, it would essentially be returned as <any>.
From a architecture / library creator point of view, I want to create an interface, and I want to hand out that interface to consumers of my Library, so they can work off the explicit constraints.
In my case, the library is creating a system, that's execution, can optionally be delayed by a
Promise. In addition the promise library,
when, I'm using allows you to also delay it's calls, such as reduce or map, also with a promise (or returning a value).
A quick example case, this is from the .d.ts file I've created so far.
This is a convention interface, so the consumer of my library can create a strongly typed object. They can choose to either return a Promise, an Array of Promises, or nothing (void).
init(mod: IModule, facades: IModuleFacades): Promise;
If we could turn this around and also say, that well you can return a promise or an array of Promises, or nothing, you should be able to state that explicitly without just typing it to any.
init(mod: IModule, facades: IModuleFacades): [Promise | Promise | void];
Currently I'm using multiple interfaces to handle these scenarios, but then you have to involve extra process, and needs to be documented and understood, and users need to be trained. This functionality would clearly state the allowed return types,
to the consuming developer.
Thoughts? Is this a terrible idea, something that could be of use?