Typescript 键的联合类型，字典值的推断类型

Question

I am trying to write a type which expresses the below without needing to explicitly create a type for the translations dictionary.

type Language = "english" | "german" | "french";

const translations = {
  english: {
    foo: "foo",
    bar: "bar"
  },
  german: {
    foo: "föö"
  }
};

I have come up with this

type Translations = {english: T, } & {[key in Language]?: Partial<T>};

but this doesn't quite satisfy my requirements, as T still needs to be passed to the type parameter...

Answer 1

TypeScript cannot express Translations as a specific type. What you'd need is a different sort of generic type that most languages with generics doesn't have: a so-called existentially quantified generic type , or sometimes just existential type . In your Translations type, you have a type parameter T ... but you don't want to have to specify it. Instead, you want to say "the person who supplies a Translations value should be allowed to specify T to whatever they want; all I care or know about is that such a T exists ." Maybe such a type definition would look like this:

/* NOT SUPPORTED
type Translations = <exists T extends Record<keyof T, string>>(
  { english: T } & { [K in Language]?: Partial<T> }
);
*/

But of course, you can't do this. There is no exists keyword in TypeScript and no direct method to quantify generic type parameters this way. There's a feature request at microsoft/TypeScript#14466 for existential types, but it's not clear if that feature will ever be implemented.

There are ways to emulate existential types in TypeScript, but they are a bit convoluted and strange to use. Instead of trying to do this, let's give up on existential types and instead look at possible workarounds.

---

The most straightforward workaround is to define Translations<T> as a generic constraint on the type, with a type parameter T :

type Translations<T extends Record<keyof T, string>> = 
  { english: T } & { [K in Language]?: Partial<T> };

To avoid requiring the user to specify T in a type annotation, you can make a helper function:

const asTranslations = <T extends Record<keyof T, string>>(
  translations: Translations<T>) => translations;

This identity function just returns its input, so at runtime it's essentially a no-op. But by constraining the input to Translations<T> , we are asking the compiler to infer the generic type T from the input. If the call compiles with no errors, then we know that the input is valid:

const translations = asTranslations({
    english: {
        foo: "foo",
        bar: "bar"
    },
    german: {
        foo: "föö"
    }
}); // okay
/* const translations: Translations<{
  foo: string;
  bar: string;
}> */

Here the compiler has inferred that T is {foo: string, bar: string} and therefore translations is inferred to be of type Translations<{foo: string, bar: string}> .

If you make a mistake, the compiler will warn you about it:

const badTranslations = asTranslations({
    english: {
        foo: "foo",
        bar: "bar"
    },
    german: {
        foo: "föö",
        baz: "baß" // error!
    //  ~~~~~~~~~~
    // Type '{ foo: string; baz: string; }' is not assignable 
    //    to type Partial<{ foo: string; bar: string; }>' 
    // Object literal may only specify known properties, and 'baz' 
    //    does not exist in type 'Partial<{ foo: string; bar: string; }>'
    }
});

In this case too, the compiler infers {foo: string; bar: string} {foo: string; bar: string} for T . But this time, there is an excess property warning on the baz property of german , because baz is neither foo nor bar .

(Note that excess property warnings only happen with object literals. If you need to copy your object literal to a variable before calling asTranslations() on it, you won't get the warning. If that use case is important, you can switch to a different definition for Translations<T> , but I won't bother going into that here unless there's some need for it. It's in the linked Playground Code example below anyway.)

---

One side effect of this workaround is that you will be required to make anything that deals with a Translations<T> type generic itself. You can plausibly free up end users from having to specify T , but your code base will still end up dragging around an extra type parameter. For example, a function which ideally would look like function saveTranslations(translations: Translations, filename: string): void {} will now look like function saveTranslations<T extends Record<keyof T, string>>(translations: Translations<T>, filename: string): void {} .

For that reason, it might be best to only require such a generic type in a validation function that accepts the input, and then in your internal library code you widen the type to something less accurate but easier to use:

function userFacingFunction<T extends Record<keyof T, string>>(
  translations: Translations<T>) {
    internalLibraryFunction(translations);
}

type AnyTranslations = Translations<Record<string, string>>;
// not generic anymore
function internalLibraryFunction(translations: AnyTranslations) {
    // do something 
}

---

Playground link to code