Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

String literal type for use in single-property mapped types #25019

Closed
4 tasks done
magnushiie opened this issue Jun 16, 2018 · 3 comments
Closed
4 tasks done

String literal type for use in single-property mapped types #25019

magnushiie opened this issue Jun 16, 2018 · 3 comments
Labels
Question An issue which isn't directly actionable in code

Comments

@magnushiie
Copy link
Contributor

Search Terms

  • string literal indexer mapped type
  • string literal
  • mapped type

Suggestion

Add a new type (stringliteral in the example below) that would be a super-type of all string literals, but not unions.

Use Cases

Mapped types are great when building an object out of another object, or when starting with object literals with constant property names. There currently doesn't seem to be an option to build out an object typed with mapped types with variable property names.

Examples

We can build an algebra of base object construction and composition functions.

Note: this example composes plain objects, but the actual motivation is to have more complex structures that internally maintain a typed object and the algebra allows composing them in various ways.

const singlePropertyObject = <N extends string, V>(n: N, v: V): { [P in N]: V } =>
  ({ [n]: v } as { [P in N]: V }); // note: cast required
const compose = <O1 extends object, O2 extends object>(o1: O1, o2: O2) =>
  Object.assign({}, o1, o2);

const oa = singlePropertyObject('a', 'v1'); // { a: string; }
const ob = singlePropertyObject('b', 'v1'); // { b: string; }
const oab = compose(oa, ob);

But this is unsafe - singlePropertyObject can be used to create arbitrary objects with non-optional fields but without value without type errors:

const oaUnsafe = singlePropertyObject<'a' | 'b', string>('a', 'v1'); // { a: string; b: string; }

The current behavior is of course correct, in that { [n]: V } can be implicitly cast only to { [P in N]?: V } - if N is a union, the other members of the union don't have a value set.

What could help is to narrow the generic argument N to a single string literal to prevent unions:

const singlePropertyObject = <N extends stringliteral, V>(n: N, v: V): { [P in N]: V } =>
  ({ [n]: v }); // note: no cast required anymore

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. new expression-level syntax)
@jack-williams
Copy link
Collaborator

Does this work?

type SingletonStringImpl<N extends string, M extends string> =
    N extends N ? [M] extends [N] ? N : never : never;

type SingletonString<N extends string> = SingletonStringImpl<N,N>

const singlePropertyObject = <N extends string, V>(n: N & SingletonString<N>, v: V): Record<N, V> =>
    ({ [n as N]: v } as Record<N, V>); // note: cast required

const compose = <O1 extends object, O2 extends object>(o1: O1, o2: O2) =>
  Object.assign({}, o1, o2);

const oa = singlePropertyObject('a', 'v1'); // { a: string; }
const ob = singlePropertyObject('b', 'v1'); // { b: string; }
const oab = compose(oa, ob);

const oaUnsafe = singlePropertyObject<'a' | 'b', string>('a', 'v1'); // Static error

@mhegazy
Copy link
Contributor

mhegazy commented Jun 19, 2018

The type used in the OP { [P in N]: V } is not correct. it is more like:

type Unionize<T extends string, V> = { [P in T]: { [Q in P]: V } }[T];

See #18155 for more details.

@mhegazy mhegazy added the Question An issue which isn't directly actionable in code label Jun 19, 2018
@typescript-bot
Copy link
Collaborator

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Question An issue which isn't directly actionable in code
Projects
None yet
Development

No branches or pull requests

4 participants