Recursively-typed array with nth-element typing

[harrysolovay]

Search Terms

• recursive (tuple|array) of varying length
• differently-typed array elements
• tuple of (generic|unknown) size

Suggestion

Ability to recursively type the elements of varying-length arrays

Use Cases

I'm attempting to create a type for hypertext nodes. Consider the following representation of some HTML:

["div", {"id": "parent"},
  ["div", {"id": "first-child"}, "I'm the first child"],
  ["div", {"id": "second-child"}, "I'm the second child"]
]

This is similar to the arguments of React's createElement. While it's possible to type the arguments array of a function and account for rest spread type... this doesn't seem doable in a standalone array. Meanwhile, tuples must be of fixed length. One solution would be to define this hypertext within call expressions:

h("div", {id: "parent"},
  h("div", {id: "first-child"}, "I'm the first child"),
  h("div", {id: "second-child"}, "I'm the second child"),
)

However, this format is more bloated. It doesn't convey the most minimal format for the data. My sense is that I should––for the time being––make use of any[].

By the way, apologies if this is currently possible and I just did not find it! Looked for quite a while & no approach seemed to do the trick.

Examples

export type HypertextNodeStructure<T, P, C> = [T, P, ...C[]];
export interface HypertextNode
  extends HypertextNodeStructure<string, {[key: string]: any}, HypertextNode> {}

const hypertextNode: HypertextNode =
  ["div", {id: "parent"},
    ["div", {id: "first-child"}, "I'm the first child"],
    ["div", {id: "second-child"}, "I'm the second child"]
  ]

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[harrysolovay]

@manueliglesias & @mikeparisstuff –– tagging you two in this thread, incase you're interested in watching for the resolution 👍

[dragomirtitian]

@harrysolovay Not ideal, but this could be a workaround:

type Others = 2|3|4|5|6|7|8|9|10|12|13|14|15|16|17|18|19|20; // Up to reasonable number.
type HypertextNodeStructure<T> = unknown[] & {
  0: string,
  1: Record<string, any> 
} & Partial<Record<Others, T | string>>
interface HypertextNode extends  HypertextNodeStructure<HypertextNode>{}

let x: HypertextNode = ["div", { id: "" },
  ["div", {"id": "first-child"}, "I'm the first child"],
  ["div", {"id": "second-child"}, "I'm the second child"]
]

let d0 = x[0] // string
let d1 = x[1] // Record<string, any>
let d2 = x[2]  // string | HypertextNode | undefined

Play

[harrysolovay]

Thanks @dragomirtitian ... but in the case of long lists (1000+ windowed elements), this wouldn't be good :/

Any other idea?

[AnyhowStep]

interface HypertextNode extends Array<string|Record<string, unknown>|HypertextNode> {
    0 : string,
    1 : Record<string, unknown>
}

const node : HypertextNode = ["div", {id: "parent"},
    ["div", {id: "first-child"}, "I'm the first child"],
    ["div", {id: "second-child"}, "I'm the second child"]
];

Playground

[harrysolovay]

YESSS. That did the trick. Thank you @AnyhowStep !!!

[AnyhowStep]

Wait-

But my approach allows Record<string, unknown> for elements at index 2,3,4,etc. though.

Is that what you actually want?

---

@dragomirtitian 's approach is closer to what you want, even if there's a limit

---

How... Deep can these hierarchies get?

---

[Edit]
You should re-open the issue because I think it's a good feature request.
At least until someone has a workaround that is not too hacky, supports deeply nested tuples, supports arbitrarily long tuples, has the behaviour you want for rest params, etc.

[harrysolovay]

Good catch. It also allows string for those indices :/

Is it possible to give the right index signatures for 0 and 1? This might let us do the following:

type Base<T> = Array<T>;
export interface H extends Base<H> {
  0: string;
  1: Record<string, unknown>;
}

Currently it throws Property '1' of type 'Record<string, unknown>' is not assignable to numeric index type 'H'.ts(2412)

[dragomirtitian]

@harrysolovay The limitation here is that an index signature must be consistent with all defined properties, and there is no way to exclude a subset of properties from the index.

@weswigham has an interesting combo of PRs that address this negated types and Allow any key type as an index signature parameter type that might allow us to write something like this in the future:

export interface H {
  0: string;
  1: Record<string, unknown>;
  [index: not 0 & not 1 & number]: H
}

[harrysolovay]

@dragomirtitian that is fantastic! Would that work when extending Arrays? It'd be nice to see a shorthand for rest type as well. Something like this:

export interface H {
  0: string;
  1: Record<string, unknown>;
  [...indices: number[]]: H;
}

[fatcerberus]

In my experience a lot of people already tend to expect the index signature to act as a "rest type" and are surprised when it doesn't, so having that actually in the language would be great.

[weswigham]

FYI for everyone here: Tuples are pretty great - [string, Record<string, unknown>, ...number[]]