Utilizing index signatures in TypeScript mapped types

Question

Utilizing index signatures in TypeScript mapped types

Is there a way to abstract over the type

{ 'k': number, [s: string]: any }

by creating a type alias T such that T<'k', number> results in the desired type?

Take a look at the following example:

function f(x: { 'k': number, [s: string]: any }) {}                           // ok
type T_no_params = { 'k': number, [s: string]: any };                         // ok
type T_key_only<k extends string> = { [a in k]: number };                     // ok
type T_value_only<V> = { 'k': V, [s: string]: any};                           // ok
type T_key_and_index<k extends string, V> = { [a in k]: V, [s: string]: any };// ?

Directly using { 'k': number, [s: string]: any} as the type of the parameter in the function f is acceptable.
The indexed part [s: string]: any in a type alias works correctly
Using k extends string in a type alias also functions as expected
However, attempting to combine k extends string with [s: string]: any in the same type alias results in a parse error.

One approach that seems to work is:

type HasKeyValue<K extends string, V> = { [s: string]: any } & { [S in K]: V }

But it is unclear why this does not flag extra properties as errors (the type on the right side of the & should not allow objects with additional properties).

EDIT:

Despite the & being the intersection operator, behaving akin to set-theoretic intersection, it does not handle extra properties in the same way, as evidenced by the following example:

function f(x: {a: number}){};
function g(y: {b: number}){};
function h(z: {a: number} & {b: number}){};

f({a: 42, b: 58});  // does not compile. {a: 42, b: 58} is not of type {a: number}
g({a: 42, b: 58});  // does not compile. {a: 42, b: 58} is not of type {b: number}
h({a: 42, b: 58});  // compiles!

In the above example, it appears that {a: 42, b: 58} neither matches {a: number} nor {b: number}, yet it combines as {a: number} & {b: number}. This deviates from set-theoretical intersection principles.

This inconsistency raises doubts about how intersecting a mapped type with { [s: string]: any } could expand the type rather than restrict it.

I've come across similar inquiries like:

Index signature for a mapped type in Typescript
How do I add an index signature for a mapped type

Although they share a resemblance in name, they do not directly address the issue at hand.

typescript types mapped-types

Answer 1

Answer №1

type HasKeyAndValue<K extends string, V> = { [s: string]: any } & { [S in K]: V }

is the precise way to define the desired type. However, it's important to note that the keyof type operator can return string | number instead of just string when used on a type with a string index signature.

The keyof type operator will return string | number instead of string when applied to a type with a string index signature.

It's currently unknown how to restrict the index to only be the string type and not string | number. Allowing number to access string index seems reasonable as it aligns with Javascript behavior, where a number can always be stringified. Conversely, accessing a number index with a string value is not safe.

The & type operator functions like set theoretic intersection - it always limits the set of potential values (or keeps them the same, never expanding them). In this case, the type excludes any non-string-like keys as an index, specifically excluding unique symbols as an index.

Your confusion may arise from how Typescript handles function parameters. Passing parameters as explicitly defined variables differs from passing them as variables. In both scenarios, Typescript ensures that all parameters have the correct structure/shape; however, in the latter case, it also disallows additional properties.

View the code demonstrating these concepts:

type HasKeyAndValue<K extends string, V> = { [s: string]: any } & { [S in K]: V };
type WithNumber = HasKeyAndValue<"n", number>;
const x: WithNumber = {
  n: 1
};

type T = keyof typeof x; // string | number
x[0] = 2; // okay - number is treated as a string-like index
const s = Symbol("s");
x[s] = "2"; // error: cannot access via symbol

interface N {
  n: number;
}

function fn(p: N) {
  return p.n;
}

const p1 = {
  n: 1
};

const p2 = {
  n: 2,
  s: "2"
};

fn(p1); // okay - exact match
fn(p2); // okay - structural matching: { n: number } present; additional props ignored
fn({ n: 0, s: "s" }); // error: additional props not ignored when called explicitly
fn({}); // error: missing n property

EDIT

When creating object literals with a specific shape, like

const p: { a: number} = { a: 42 }

, Typescript treats them differently. Unlike regular structural inference, the type must be an exact match. This makes sense as those extra properties are inaccessible without additional potentially unsafe casting.

[...] However, TypeScript assumes that there might be a mistake in this code. Object literals are subject to excess property checking when assigned to different variables or passed as arguments. Any object literal properties not present in the "target type" will result in an error. [...] Assigning the object to another variable is a surprising workaround.

TS Handbook

Another method to address this error is to intersect it with { [prop: string]: any }.

Additional code examples:

function f(x: { a: number }) {}
function g(y: { b: number }) {}
function h(z: { a: number } & { b: number }) {}

f({ a: 42, b: 58 } as { a: number }); // compiles - casting possible, but `b` is inaccessible anyway
g({ a: 42 } as { b: number }); // does not compile - incorrect cast; Conversion of type '{ a: number; }' to type '{ b: number; }' may be a mistake
h({ a: 42, b: 58 }); // compiles!

const p = {
  a: 42,
  b: 58
};

f(p); // compiles - regular structural typing
g(p); // compiles - regular structural typing
h(p); // compiles - regular structural typing

const i: { a: number } = { a: 42, b: 58 }; // error: not an exact match
f(i); // compiles
g(i); // error
h(i); // error

Answer 2

type HasKeyAndValue<K extends string, V> = { [s: string]: any } & { [S in K]: V }

is the precise way to define the desired type. However, it's important to note that the keyof type operator can return string | number instead of just string when used on a type with a string index signature.

The keyof type operator will return string | number instead of string when applied to a type with a string index signature.

It's currently unknown how to restrict the index to only be the string type and not string | number. Allowing number to access string index seems reasonable as it aligns with Javascript behavior, where a number can always be stringified. Conversely, accessing a number index with a string value is not safe.

The & type operator functions like set theoretic intersection - it always limits the set of potential values (or keeps them the same, never expanding them). In this case, the type excludes any non-string-like keys as an index, specifically excluding unique symbols as an index.

Your confusion may arise from how Typescript handles function parameters. Passing parameters as explicitly defined variables differs from passing them as variables. In both scenarios, Typescript ensures that all parameters have the correct structure/shape; however, in the latter case, it also disallows additional properties.

View the code demonstrating these concepts:

type HasKeyAndValue<K extends string, V> = { [s: string]: any } & { [S in K]: V };
type WithNumber = HasKeyAndValue<"n", number>;
const x: WithNumber = {
  n: 1
};

type T = keyof typeof x; // string | number
x[0] = 2; // okay - number is treated as a string-like index
const s = Symbol("s");
x[s] = "2"; // error: cannot access via symbol

interface N {
  n: number;
}

function fn(p: N) {
  return p.n;
}

const p1 = {
  n: 1
};

const p2 = {
  n: 2,
  s: "2"
};

fn(p1); // okay - exact match
fn(p2); // okay - structural matching: { n: number } present; additional props ignored
fn({ n: 0, s: "s" }); // error: additional props not ignored when called explicitly
fn({}); // error: missing n property

EDIT

When creating object literals with a specific shape, like

const p: { a: number} = { a: 42 }

, Typescript treats them differently. Unlike regular structural inference, the type must be an exact match. This makes sense as those extra properties are inaccessible without additional potentially unsafe casting.

[...] However, TypeScript assumes that there might be a mistake in this code. Object literals are subject to excess property checking when assigned to different variables or passed as arguments. Any object literal properties not present in the "target type" will result in an error. [...] Assigning the object to another variable is a surprising workaround.

TS Handbook

Another method to address this error is to intersect it with { [prop: string]: any }.

Additional code examples:

function f(x: { a: number }) {}
function g(y: { b: number }) {}
function h(z: { a: number } & { b: number }) {}

f({ a: 42, b: 58 } as { a: number }); // compiles - casting possible, but `b` is inaccessible anyway
g({ a: 42 } as { b: number }); // does not compile - incorrect cast; Conversion of type '{ a: number; }' to type '{ b: number; }' may be a mistake
h({ a: 42, b: 58 }); // compiles!

const p = {
  a: 42,
  b: 58
};

f(p); // compiles - regular structural typing
g(p); // compiles - regular structural typing
h(p); // compiles - regular structural typing

const i: { a: number } = { a: 42, b: 58 }; // error: not an exact match
f(i); // compiles
g(i); // error
h(i); // error

Answer 3

Answer №2

Let's explore a different approach to understanding the intersection operator. Perhaps this analogy will provide some clarity:

type Combo = { x: string } & { y: number }

You can interpret Combo as "an entity that possesses a property x of type string and a property y of type number". This description also fits another straightforward type:

type Basic = { x: string; y: number }

Interestingly, these two types are interchangeable in most scenarios.

This should clarify why HasKeyValue essentially mirrors the type you were attempting to articulate.

Regarding the issue with T_key_and_index, it stems from the initial segment, [a in k]: V, which defines a mapped type. Mapped types do not allow additional properties. To include extra properties in a mapped type, you can utilize a type intersection using &.

Answer 4

Let's explore a different approach to understanding the intersection operator. Perhaps this analogy will provide some clarity:

type Combo = { x: string } & { y: number }

You can interpret Combo as "an entity that possesses a property x of type string and a property y of type number". This description also fits another straightforward type:

type Basic = { x: string; y: number }

Interestingly, these two types are interchangeable in most scenarios.

This should clarify why HasKeyValue essentially mirrors the type you were attempting to articulate.

Regarding the issue with T_key_and_index, it stems from the initial segment, [a in k]: V, which defines a mapped type. Mapped types do not allow additional properties. To include extra properties in a mapped type, you can utilize a type intersection using &.

Utilizing index signatures in TypeScript mapped types

Answer №1

EDIT

Answer №2

Similar questions

esBuild failing to generate typescript declaration files while running in watch mode

What steps should I take to establish a one-to-one relationship with legacy tables?

Tips for accessing the 'index' variable in *ngFor directive and making modifications (restriction on deleting only one item at a time from a list)

Transform a group of objects in Typescript into a new object with a modified structure

Executing Promises in TypeScript Sequentially

Alerts appear immediately upon beginning to type, asking for 8 characters and ensuring both passwords match

Is there a solution for the error "Unable to persist the session" in a Next.js application that utilizes Supabase, Zustand, and Clerk.dev for authentication?

The method toLowerCase is not found on this data type in TypeScript

A guide on incorporating unique font weights into Material UI

The attribute 'pixiOverlay' is not found in the property

Access-Control-Allow-Origin header not being sent by ExpressJS

Is there a method in typescript to guarantee that a function's return type covers all possibilities?

What is preventing me from setting the User object to null in my Angular application?

IE11 is throwing a fit because of a pesky long-running script error caused by the powerful combination of Webpack, React,

Having trouble with Angular 2's Output/emit() function not functioning properly

Eliminating every instance of the character `^` from a given string

Is there a way for me to maintain a consistent layout across all pages while also changing the content component based on the URL route in Next.js?

Encountering a Typescript error while attempting to convert a JavaScript file to Typescript within an Express

Tips for converting a string array constant into a union type

Angular 4 and Webpack: Compilation Error