Strictly type a object's values whilst maintaining its keys

[bradzacher]

Search Terms

properties, object, keys, strict typing

Suggestion

A way to strictly type a object's values whilst maintaining its property keys.

Use Cases

A pattern we end up using a bit in our code is config objects with a constant set of keys, whose values must adhere to a strict structure.

The problem is that the only way I've found to achieve this is by using noop functions, or double variable definitions:

type PropKeyType = string | number | symbol
type Foo<T extends PropKeyType> = {
	[k in T] : { someNestedValue : boolean }
}
type SuboptimalFoo = {
    [k : string] : { someNestedValue : boolean }
}

function noopTyper<T extends PropKeyType>(x : Foo<T>) : Foo<T> {
	return x
}

// strictly types the values, keeps the keys, but requires a noop function
const x = noopTyper({
	a: { someNestedValue: true },
	b: { someNestedValue: false },
})
type Kx = keyof typeof x // 'a' | 'b'

// strictly types the values, keeps the keys, but requires doubly defining the variable
const yUntyped = {
	c: { someNestedValue: true },
	d: { someNestedValue: false },
}
const y : Foo<keyof typeof yUntyped> = yUntyped
type Ky = keyof typeof y // 'c' | 'd'

// strictly types the values, but looses the keys
const z: SuboptimalFoo = {
	e: { someNestedValue: true },
	f: { someNestedValue: false },
}
type Kz = keyof typeof z // string | number

It would be great if there was a way to use this pattern without having to resort to techniques that output additional, useless code that is run at runtime.

The following two definitions would be good, however they both fail hard at compile time.

const a = {
	a: { someNestedValue: true },
	b: { someNestedValue: false },
} as Foo<keyof typeof a> // Block-scoped variable 'a' used before its declaration.

const b                       // 'b' is referenced directly or indirectly in its own type annotation.
    : Foo<keyof typeof b> = { // Block-scoped variable 'b' used before its declaration.
	c: { someNestedValue: true },
	d: { someNestedValue: false },
}

This pattern is used regularly with libraries like JSS which require you to declare css class lists for a component at definition time.
Within your component you then can access the class names you defined:

const styles = {
	foo: { /* React.CSSProperties */ },
	bar: { /* React.CSSProperties */ },
}

interface Props {
	classes : Record<keyof typeof styles, string>
}

@withStyles(styles)
class Example extends React.Component<Props> {
	public render() {
		return (
			<div className={this.props.classes.foo}>
				<p className={this.props.classes.bar}>
					<input className={this.props.classes.baz} />{/* fails as baz is not in keyof typeof styles */}
				</p>
			</div>
		)
	}
}

Strictly typing the styles variable whilst keeping its keys requires one of the above techniques, or you can always be extremely and unmaintainably explicit:

const styles = {
	foo: { /* React.CSSProperties */ } as React.CSSProperties,
	bar: { /* React.CSSProperties */ } as React.CSSProperties,
}

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)

[RyanCavanaugh]

We don't have anything that works like this at all right now - the type of a variable is either its explicitly-annotated type, or the inferred type from its initializer. There isn't a way to mix and match type constraining and inference without a function call.

That said, maybe someone can come up with something!

It seems like the closest thing to a "best" solution is actually no annotations at all on the declaration + initializer and to just let the errors (if any) show up at a subsequent call site?

[bradzacher]

That solution does work in some cases.
There are two main problems with it, however:

1. You lose IDE support for filling out props and string values on the original variable.
2. Typescript will simplify the properties with string values from constants to string, which will break strict typings.

It'd be great if we could either figure out a little bit of syntax to add to allow it.
Or maybe (because I know it's better to not add new syntax where possible) if this example was changed so that it works, it'd be a decent middle ground I think.

const a = {
	a: { someNestedValue: true },
	b: { someNestedValue: false },
} as Foo<keyof typeof a>

[Hotell]

for exactly this you can use "casting" within implementation to maintain correct value,keys and proper type checking

Errors:

type ComplicatedObj = { someNestedValue: boolean }

const a = {
	a: { someNestedValue: true } as ComplicatedObj,
	b: { someNestedValue: 'dsfds' } as ComplicatedObj,
}
type K = keyof typeof a

Correct with all intellisense and types preserved:

type ComplicatedObj = { someNestedValue: boolean }

const a = {
	a: { someNestedValue: true } as ComplicatedObj,
	b: { someNestedValue: false } as ComplicatedObj,
}
type K = keyof typeof a

[bradzacher]

You can indeed do that - it's one of the two type-only solutions I've seen.
It's (I think) the only way to do it and still get intellisense, as well as type errors on the correct line.

The problem is that it's not maintainable at scale.

For example, when using JSS.. If I have a small app of ~100 react components, and each one has ~5 css classes defined for it. Then that's ~500+ as React.CSSProperties you have to have around the place.

It makes the code ugly, verbose, and is cumbersome to write.
Plus, if a developer forgets just one - things could potentially compile fine and then break at runtime.

[RyanCavanaugh]

Tracking at #7481

[typescript-bot]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.