Quick fix for 'unions can't be used in index signatures, use a mapped object type instead'

The following code:

type K = "foo" | "bar";

interface SomeType {
    [prop: K]: any;
}

Gives this error message:

An index signature parameter type cannot be a union type. Consider using a mapped object type instead.

Nobody knows what mapped object types are, so let's give them a quick fix that

Switches the index signature to a mapped type
Moves other members to a separate object type that gets combined with an intersection type
Changes the containing object type to a type alias if the containing object type is an interface
Intersects with all the extends clauses if the containing object type is an interface and has any extends clauses

Nobody knows what mapped object types are, so let's give them a quick fix that

+1, just came here because I was expecting 2.9 to support unions as index signatures per your example code. I think this has been a long desired feature: #5683, #16760, etc..

You can do this:

type Foo = 'a' | 'b';
type Bar = {[key in Foo]: any};

Though Bar has no index signature (i.e., you can't then do (obj as Bar)[value as Foo]).

Edit: Though if you could make the caveat a non-issue, I'd be eternally grateful!

i'd like to work on this 😆

Moves other members to a separate object type that gets combined with an intersection type

what should we do if containing object type is an class?
I can only imagine that it is an interface

so what should follow code do after quickfix?

type K = "1" | "2"

class SomeType {
    a = 1;
    [prop: K]: any;
}

so what should follow code do after quickfix?

I would say this should not be fixable..

Mohamed Hegazy (@mhegazy)

Mohamed Hegazy (@mhegazy) I'm using 3.0.0-rc and still getting the same error as originally posted. Is this expected?

I'm using 3.0.0-rc and still getting the same error as originally posted. Is this expected?

yes. the error is correct. this issue was tracking adding a quick fix for it, that is the light pulp next to the error message.

Filippo Conti (@b4dnewz)

Filippo Conti (@b4dnewz) You can't do it in Typescript. Workaround: #10575

Filippo Conti (@b4dnewz)

Filippo Conti (@b4dnewz), if you only want 1 property, why not do it like this?

export enum BitwiseOperator {
  and = "and",
  or = "or",
  xor = "xor",
}

export type BitwiseCondition = {
  operator: BitwiseOperator;
  value: number;
}

Ben Winding (@benwinding)

Ben Winding (@benwinding) unfortunately the returned shape is different from what mongodb expects

Bartek (@apieceofbart) thanks for the suggestion, I've looked into it, a bit redundant in terms of interfaces but can work, I'm not sure if I'll implement it now, since it's not a big deal if the final user tries a bitwise condition with two operators, mongo will throw an error anyway

I'm trying to keep the mongo-operators definitions as simple as possible to avoid me headaches 😁 maybe in future a proper support is added

Filippo Conti (@b4dnewz)

Filippo Conti (@b4dnewz) fair enough,

Perhaps a simpler option you might be able to use is:

export type BitwiseCondition =
  | { or: number }
  | { xor: number }
  | { and: number }

That's about the closest you'll get without too much duplication

Filippo Conti (@b4dnewz)

Filippo Conti (@b4dnewz) fair enough,

Perhaps a simpler option you might be able to use is:
export type BitwiseCondition =
  | { or: number }
  | { xor: number }
  | { and: number }
That's about the closest you'll get without too much duplication

This will not yield error in this example:

const query: BitwiseCondition = {
  and: 5,
  or: 6  // raise a ts error
};

I thought that's the whole point

Bartek (@apieceofbart)

Bartek (@apieceofbart),

This will not yield error in this example:

export type BitwiseCondition =
  | { or: number }
  | { xor: number }
  | { and: number }

const query: BitwiseCondition = {
  and: 5,
  or: 6  // doesn't raise a ts error!
};

Woah! that's weird 😮 I did not know that!

It's seems that Typescript doesn't support mutually exclusive types for objects. It's also was proposal for the language here: #14094

It is still technically possible though...

From this stackoverflow answer this is possible to achieve this using conditional types (the hardest types), but it aint pretty....

/*
 XOR boiler plate
*/
type Without<T, U> = { [P in Exclude<keyof T, keyof U>]?: never };
type XOR<T, U> = T | U extends object
  ? (Without<T, U> & U) | (Without<U, T> & T)
  : T | U;
type XOR3<S, T, U> = XOR<S, XOR<T, U>>;

// Code start
export type BitwiseCondition = XOR3<
  { or: number },
  { xor: number },
  { and: number }
>;

const query1: BitwiseCondition = {
  and: 5
};

const query: BitwiseCondition = {
  and: 5,
  or: 6 // raise a ts error
};

If anyone could make this prettier or better, please do

Michael Vasin (@mvasin)

Michael Vasin (@mvasin) FWIW, this appears to achieve the same result, but I agree entirely that it should be a feature of interfaces just as it is on types.

type Foo = 'a' | 'b';

type Bar = {
  [key in Foo]: any
}

interface A extends Bar { }

class Wol implements A{
  a: any;
  b: any;
}

For typescript 3.5, it seems like I have to do this:

export interface DataTableState {
  columnStats: {[key in keyof DataTable]?:{}}
}

Is this the best way to do this?

Why exactly can't an index signature use an enum type? The mapped type almost does what I want, but then TypeScript expects every string from the enum to exist as a defined key. I don't actually want to assert that every key exists, more that if any keys do exist, they must live in the enum.

For example for the type:

type MyType = {
  [Key: 'foo' | 'bar' | 'zip']: number;
};

This should satisfy:

const x: MyType = {
  foo: 1,
  zip: 2
};

While I could just set the other keys undefined for a mapped type, I prefer to make the keys optional, but if they're present, the value cannot be undefined. If I make the mapped type values optional the code works but the types are less strong.

its even better when using Partial
type A = 'x' | 'y' | 'z';
type M = Partial<{
    [key in A]: boolean
}>;

Thanks!
Useful when you need to define a type that partially matches a dictionary

https://www.typescriptlang.org/docs/handbook/advanced-types.html#mapped-types

"Partial" can be used on Records too:

type Foo = 'a' | 'b';
let foo1: Record<Foo, number> = { a: 1, b: 2 };
let foo2: Partial<Record<Foo, number>> = { a: 1 };

I find myself unwittingly visiting this GitHub page every month or so.

My latest one is a real simple one:

interface ObjectLiteral {
    [key: string | number]: any
}
export const mapToObjectLiteral = (map: Map<string|number, any>) =>
    Array.from(map).reduce((objLit, [key, value]) => {
        objLit[key] = value
        return objLit
    }, {} as ObjectLiteral)

I can scroll up and figure out a workaround, but just wanted to provide feedback that this issue happens frequently in day to day work in slightly different scenarios.

here is an example:

type MapKey = string | number;
type ObjectLiteral<T extends MapKey, V = any> = {
  [P in T extends number ? string : T]: V;
};

export const mapToObjectLiteral = <T extends MapKey, V>(map: Map<T, V>) =>
  Array.from(map).reduce((objLit, [key, value]) => {
    objLit[key as keyof ObjectLiteral<T>] = value;
    return objLit;
  }, {} as ObjectLiteral<T, V>);

// how to make a better type of map ?
const m = new Map<1 | "foo", "a" | "b">();
m.set(1, "a");
m.set("foo", "b");

const o = mapToObjectLiteral(new Map(m));

console.log(o[1], o.foo); // just got an union type of every member of 'o'

#24220 (comment)

To add one more example of this using a class...

class Foo {
   a: string;
   b: string;
}

type Bar = {[key in keyof Foo]: any};

Very useful. Thanks! 🚀

Navigation Menu

Repository navigation

Quick fix for 'unions can't be used in index signatures, use a mapped object type instead' #24220

18 remaining items

It is still technically possible though...

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Quick fix for 'unions can't be used in index signatures, use a mapped object type instead' #24220

Description

Activity

dannycochran commented on May 18, 2018

mattbasta commented on May 18, 2018

Kingwl commented on May 20, 2018

Kingwl commented on May 21, 2018

mhegazy commented on May 21, 2018

dannycochran commented on Jul 18, 2018

mhegazy commented on Jul 18, 2018

18 remaining items

apieceofbart commented on Dec 24, 2019

benwinding commented on Dec 24, 2019

b4dnewz commented on Dec 25, 2019

benwinding commented on Dec 25, 2019

apieceofbart commented on Jan 2, 2020

benwinding commented on Jan 3, 2020

It is still technically possible though...

daverickdunn commented on Jan 13, 2020

chriszrc commented on Jan 17, 2020

benwiley4000 commented on Mar 5, 2020

defusioner commented on Mar 18, 2020

ruojianll commented on Apr 13, 2020

ZYinMD commented on Aug 2, 2020

breck7 commented on Oct 16, 2020

iahu commented on Oct 22, 2020

nelson6e65 commented on Nov 1, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions