Render all members of an intersection type

[jeremymeng]

• I have checked issues with enhancement label and found no duplicates

Problem

When look at a type I would like to know what's available. For interface/class/etc. I can see their members. It would be great if I can see the members of an intersection type as well in one place. Currently I have to click on each type to view members of each type.

Suggested Solution

Some way to show the expanded member list for a intersection type at its doc so I don't have to do extra clicks to see its members.

[MrTelanie]

currently i am playing around a similar problem.
I want to use that type aliases for multiple function outlines.

I found out you can have multiple keys of same kind in an object.

/* eslint-disable no-dupe-keys */
export const Test = {
  test: (a, b) => 1,
  test: (a, b, c) => 1,
};

With that typedoc behaves like using function overload.

Currently on this i could not export functions directly. After searching for crazy valid characters of names, i found lots funny chars.
Valid JavaScript variable names in ES5 · Mathias Bynens

now i use \u02D0 (looks like ː) but you also could use \u200C as invisible char, but its invisible and confussing in your IDE too :D.

/**
 * @typedef {(alg: Alg) => PointType} PointAlg
 * @typedef {(x: number , y: number) => PointType} PointCon
 * @typedef {PointAlg & PointCon} point
 * @type {point}
 * @hidden
 */
export function point(x, y) {
  return pointFactory(x, y);
}

/**
 * @type {PointCon}
 */
export function point\u02D0(x, y) {
  return pointFactory(x, y);
}

/**
 * @type {PointAlg}
 */
export function point\u02D0\u02D0(alg) {
  return pointFactory(alg);
}

Now i get two entries in the create docs.

[Gerrit0]

@MrTelanie that is... horrible. I think your issue, and the original request, would be better off with a custom theme.

---

Rendering all elements of an intersection could quickly become incredibly large, a custom theme to handle this doesn't seem like a bad idea, but rendering everything by default would be problematic.

type Z = HTMLElement & File // => Huge number of properties

[MrTelanie]

until now i thought a custom theme is only for design. i will have a look for that.

Thanks to @Gerrit0

[Gerrit0]

Marking this as a plugin idea as I think it can be achieved with a plugin cleanly. I might give this a shot eventually, but there are higher priority issues. My idea is that you should be able to annotate a type with @inline, and the plugin will find references to that type and replace it with the contents of that type.

This removes the problem where rendering all elements of an intersection could explode in complexity.

[VanTanev]

@Gerrit0 Can you give some guidance as to how I could approach writing this plugin? I do need this feature, and if it's not too complex I can try to write it.

[Gerrit0]

Here's how I would approach this.

1. Create a plugin which listens to Converter.EVENT_CREATE_DECLARATION, checks if the reflection is a type alias and has an @inline comment, and add it to a saved array.
2. Also listen to Converter.EVENT_RESOLVE. This happens after EVENT_CREATE_DECLARATION. At this point, you can check the types on the reflection to find reference types which refer to a type in your saved array of inline variables and replace them with the cloned type. https://github.com/socsieng/typedoc-plugin-typescript-declaration/blob/54de68eb2a02264e22bb47d833d5f1e246244039/src/convert/unresolved-types-mapper.ts does something similar.

It would be really nice to have a transformer API that can eliminate the traversal logic... I've opened #1325 as a place to discuss that and hopefully come up with something.