Shorten method signatures (aka "type madness")

[bowdenk7]

Some of the types that make everything work behind the scenes are ridiculous. For example, from Vue.js:

For a Vue developer creating a new Vue instance in JavaScript, they will be exposed to this every time. If they already know what arguments to supply, this does not do a great job as a quick reminder. If they don't know what args to supply, this is probably not very helpful either. We should be able to give users an option to show a concise method signature like the following.

In this example, the tildas indicate that there is "type madness" hidden below. If the user really wants to see the types, they can goToDefinition or maybe we could give them a way to expand the signature window.

We would need to pick some arbitrary line when to display type information and when to hide it. My initial thinking is something along the lines of:

• Hide all generic types, but leave angle brackets in
• Hide types when there are more than 2 unions or intersections
• Show string literals if less than 100 characters (roughly 2 lines?)

I would imagine we would also want to give JavaScript users the concise signature by default and TypeScript users the full signature by default, but give both the camps the ability to configure to their preference.

[mhegazy]

I would say it should look something like:

with the definition changed to:

type VueOptions<D, M, C, P extends string> = ComponentOptions<D, M, C, P[]> & ThisType<D & M & C & Record<P, any> & Vue<D, M, C, P>>;
type VueComponent<D, M, C, P extends string> = D & M & C & Record<P, any> & Vue<D, M, C, Record<P, any>>;
interface Vue<D, M, C, P> { }
interface ComponentOptions<D, M, C, P> { }

declare function vue<D, M, C, P extends string>(options: VueOptions<D, M, C, P>): VueComponent<D, M, C, P>;

First shorten the name of the type parameters, and abstract the interesting parts of the type into their own components.

I do not think we should just elide some type parameters just because there is a long type, sometimes these are what you are looking for when you hover over a function/type; i personally do this all the time.

[DanielRosenwasser]

Another great example: https://twitter.com/smithkl42/status/842109152654581760

[RyanCavanaugh]

Need a formal description of what should happen

[Jessidhia]

@RyanCavanaugh In the backlog slog, you mention "Encourage people to write type aliases" -- however, type aliases are not used when printing the type in the tooltips. Only class and interface types are shown by their declared name, but type are always replaced by their value.

Compare

type	interface

[RyanCavanaugh]

Odd... that should not be happening.

[axefrog]

I agree that unconditional expansion of type aliases is a real problem when writing code. In VS Code, for example:

This is actually a more-readable example of some of the horrible walls of text we get in many cases. The actual types for the above screenshot are:

export interface SelectorSource<TOut, TIn, TParent extends PotentialValue<TIn>, TSignal>
  extends Source<Selector<TOut>, TIn, TParent, TSignal> {}

export type Selector<TOut> = {
  [P in keyof TOut]: TOut | Selector<TOut[P]> | Source<TOut[P]> | SelectorSource<TOut[P], any, any, any>
};

export type PotentialSource
  <TOut, TIn, TParent extends PotentialValue<TIn>, TSignal>
  = Source<TOut, TIn, TParent, TSignal>
  | SelectorSource<TOut, TIn, TParent, TSignal>;

export type PotentialValue
  <TOut = any, TIn = any, TParent extends PotentialValue<TIn> = any, TSignal = any>
  = TOut
  | Selector<TOut>
  | Source<TOut, TIn, TParent, TSignal>
  | SelectorSource<TOut, TIn, TParent, TSignal>;

export interface HyperscriptHelperFn {
  (): Selector<VNode>;
  (classNameOrId: PotentialValue<string>, data: PotentialValue<VNodeProps>, children: PotentialValue<any[]>): Selector<VNode>;
  (classNameOrId: PotentialValue<string>, data: PotentialValue<VNodeProps>): Selector<VNode>;
  (classNameOrId: PotentialValue<string>, children: PotentialValue<any[]>): Selector<VNode>;
  (classNameOrId: PotentialValue<string>): Selector<VNode>;
  (data: PotentialValue<VNodeProps>): Selector<VNode>;
  (data: PotentialValue<VNodeProps>, children: PotentialValue<any[]>): Selector<VNode>;
  (children: PotentialValue<any[]>): Selector<VNode>;
}

TypeScript's type system is a double-edged sword. You can get a lot of power from it, but if you dare to exercise that power, you're punished by unreadable tooltips and stack traces.

My suggestion: for the subsystem within the TypeScript language service that is providing the informational text, provide an option to expand or not expand aliases. In consuming applications, a hotkey or other UI option could then be provided to toggle between expanded and collapsed type alias descriptions as needed, even on a per-function-parameter basis.