What causes TypeScript to convert a string literal union type to a string when it is assigned in an object literal?

Question

What causes TypeScript to convert a string literal union type to a string when it is assigned in an object literal?

I am a big fan of string literal union types in TypeScript. Recently, I encountered a situation where I expected the union type to be preserved.

Let me illustrate with a simple example:

let foo = false;
const bar = foo ? 'foo' : 'bar';

const foobar = {
    bar
}

The variable bar is correctly typed as 'foo' | 'bar':

However, foobar.bar is being typed as string:

This discrepancy got me thinking.

Update

After considering points made by @jcalz and @ggradnig, I realized that my use case had an additional complexity:

type Status = 'foo' | 'bar' | 'baz';
let foo = false;
const bar: Status = foo ? 'foo' : 'bar';

const foobar = {
    bar
}

Interestingly, bar does have the correct type of Status, but foobar.bar still has a type of 'foo' | 'bar'.

It appears that to align with my expectations, I need to cast 'foo' to Status like this:

const bar = foo ? 'foo' as Status : 'bar';

With this adjustment, the typing behaves as desired and I am satisfied with it.

typescript union-types

Answer 1

Answer №1

When deciding to widen literals, the compiler applies various heuristics. One such heuristic is:

The type inferred for a property in an object literal is the widened literal type of the expression unless the property has a contextual type that includes literal types.

By default, a

"foo" | "bar"

gets widened to string within the assigned object literal for foobar.

UPDATE FOR TS 3.4

In TypeScript 3.4, you have the option to utilize const assertions to request narrower types:

const foobar = {
    bar
} as const;
/* const foobar: {
    readonly bar: "foo" | "bar";
} */

While the literally() function discussed later in this answer may still be relevant, it's recommended to use as const when possible.

Note the condition in the heuristic stating "unless the property has a contextual type that includes literal types." To indicate to the compiler that a type like

"foo" | "bar"

should remain narrowed, you can have it match a constrained type to string (or a union containing it).

Below is a utility function that can help achieve this:

type Narrowable = string | number | boolean | symbol | object |
  null | undefined | void | ((...args: any[]) => any) | {};

const literally = <
  T extends V | Array<V | T> | { [k: string]: V | T },
  V extends Narrowable
>(t: T) => t;

The literally() function simply returns its argument, but the type tends to be narrower. While it may not be elegant, I typically keep it in a utilities library hidden from view.

Now you can use:

const foobar = literally({
  bar
});

and the type will be inferred as

{ bar: "foo" | "bar" }

, aligning with your expectations.

Whether or not you employ something like literally(), I trust this information proves beneficial; best of luck!

Answer 2

When deciding to widen literals, the compiler applies various heuristics. One such heuristic is:

The type inferred for a property in an object literal is the widened literal type of the expression unless the property has a contextual type that includes literal types.

By default, a

"foo" | "bar"

gets widened to string within the assigned object literal for foobar.

UPDATE FOR TS 3.4

In TypeScript 3.4, you have the option to utilize const assertions to request narrower types:

const foobar = {
    bar
} as const;
/* const foobar: {
    readonly bar: "foo" | "bar";
} */

While the literally() function discussed later in this answer may still be relevant, it's recommended to use as const when possible.

Note the condition in the heuristic stating "unless the property has a contextual type that includes literal types." To indicate to the compiler that a type like

"foo" | "bar"

should remain narrowed, you can have it match a constrained type to string (or a union containing it).

Below is a utility function that can help achieve this:

type Narrowable = string | number | boolean | symbol | object |
  null | undefined | void | ((...args: any[]) => any) | {};

const literally = <
  T extends V | Array<V | T> | { [k: string]: V | T },
  V extends Narrowable
>(t: T) => t;

The literally() function simply returns its argument, but the type tends to be narrower. While it may not be elegant, I typically keep it in a utilities library hidden from view.

Now you can use:

const foobar = literally({
  bar
});

and the type will be inferred as

{ bar: "foo" | "bar" }

, aligning with your expectations.

Whether or not you employ something like literally(), I trust this information proves beneficial; best of luck!

Answer 3

Answer №2

This is due to the fact that TypeScript treats let and const differently. Constants are always assigned a "narrower" type, which in this case refers to literals. On the other hand, variables (and non-readonly object properties) are given a "widened" type, specifically string, following the rule associated with literal types.

Even though your second assignment involves a constant, the property of that constant is actually mutable as it is a non-readonly property. Without providing a specific "contextual type", the narrow inference is lost and you end up with the broader type of string.

If you want to delve deeper into literal types, you can check out this link. Here's an excerpt:

The inferred type for a const variable or readonly property without a type hint is directly based on the initializer value.

For a let variable, var variable, parameter, or a non-readonly property with an initializer but no explicit type, the widened literal type of the initializer is used.

To clarify further:

The type automatically determined for a property within an object literal is the expanded literal type of the expression, unless there is already a contextual type containing literal types.

Additionally, if you assign a contextual type to the constant, that type will extend to the variable as well:

const bar = foo ? 'foo' : 'bar';
let xyz = bar // xyz will be string

const bar: 'foo' | 'bar' = foo ? 'foo' : 'bar';
let xyz = bar // xyz will be 'foo' | 'bar'

Answer 4

This is due to the fact that TypeScript treats let and const differently. Constants are always assigned a "narrower" type, which in this case refers to literals. On the other hand, variables (and non-readonly object properties) are given a "widened" type, specifically string, following the rule associated with literal types.

Even though your second assignment involves a constant, the property of that constant is actually mutable as it is a non-readonly property. Without providing a specific "contextual type", the narrow inference is lost and you end up with the broader type of string.

If you want to delve deeper into literal types, you can check out this link. Here's an excerpt:

The inferred type for a const variable or readonly property without a type hint is directly based on the initializer value.

For a let variable, var variable, parameter, or a non-readonly property with an initializer but no explicit type, the widened literal type of the initializer is used.

To clarify further:

The type automatically determined for a property within an object literal is the expanded literal type of the expression, unless there is already a contextual type containing literal types.

Additionally, if you assign a contextual type to the constant, that type will extend to the variable as well:

const bar = foo ? 'foo' : 'bar';
let xyz = bar // xyz will be string

const bar: 'foo' | 'bar' = foo ? 'foo' : 'bar';
let xyz = bar // xyz will be 'foo' | 'bar'

Answer 5

Answer №3

Providing a solution for the updated query using a three-value literal union type:

type Status = 'foo' | 'bar' | 'baz';
let foo = false;
const bar: Status = foo ? 'foo' : 'bar';

The declared type of bar is Status, but it undergoes control flow analysis and gets narrowed down to only two possible values out of the three, which are 'foo' | 'bar'.

If you define another variable without specifying a type, TypeScript will automatically infer the type based on the assignment to bar, not the explicitly declared type:

const zoo = bar; // const zoo: "foo" | "bar"

Unless you use type assertion like as Status, there's no way to disable type inference from control flow analysis other than stating the type explicitly where necessary:

const foobar: {bar: Status} = {
    bar // now has the type Status
}

Answer 6

Providing a solution for the updated query using a three-value literal union type:

type Status = 'foo' | 'bar' | 'baz';
let foo = false;
const bar: Status = foo ? 'foo' : 'bar';

The declared type of bar is Status, but it undergoes control flow analysis and gets narrowed down to only two possible values out of the three, which are 'foo' | 'bar'.

If you define another variable without specifying a type, TypeScript will automatically infer the type based on the assignment to bar, not the explicitly declared type:

const zoo = bar; // const zoo: "foo" | "bar"

Unless you use type assertion like as Status, there's no way to disable type inference from control flow analysis other than stating the type explicitly where necessary:

const foobar: {bar: Status} = {
    bar // now has the type Status
}

What causes TypeScript to convert a string literal union type to a string when it is assigned in an object literal?

Update

Answer №1

UPDATE FOR TS 3.4

Answer №2

Answer №3

Similar questions

Can a Typescript class type be defined without explicitly creating a JavaScript class?

How can I obtain my .apk file?

Encountering a problem with Webpack SASS build where all files compile successfully, only to be followed by a JavaScript

Utilizing Mongoose RefPath in NestJS to execute populate() operation

Nested formArrays within formArrays in Angular 4

Tips for organizing your Typescript code in Visual Studio Code: avoid breaking parameters onto a

Delivering static HTML routes in a React App using Typescript

What is the best way to invoke a function in a functional React component from a different functional React component?

Ways to speed up the initial loading time in Angular 7 while utilizing custom font files

The cause of Interface A improperly extending Interface B errors in Typescript

Assign a predetermined value to a dropdown list within a FormGroup

Exploring the wonders of Angular 2: Leveraging NgbModal for transclusion within

Monitoring changes within the browser width with Angular 2 to automatically refresh the model

The variable is accessed before it is initialized in the context of Next.js and Server Actions

Having difficulty initializing a new BehaviourSubject

Creating a versatile JavaScript/TypeScript library

What is the best way for me to examine [...more] closely?

Angular2 - adding the authentication token to request headers

Passing the array as query parameters and retrieving it using the angular getAll function is the most efficient way

Guide on specifying a type for a default export in a Node.js module