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':

https://i.sstatic.net/XssIM.png

However, foobar.bar is being typed as string:

https://i.sstatic.net/Ssi5q.png

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

"Error encountered: Unable to resolve dependency tree" message appears when attempting to run npm install

Is it possible for a class method in Typescript to act as a decorator for another method within the same

Angular 6 does not automatically include the X-XSRF-TOKEN header in its HTTP requests

In Typescript, ambient warnings require all keys in a type union to be included when defining method parameter types

Determine in React whether a JSX Element is a descendant of a specific class

Using Angular's dependency injection in a project that has been transpiled with Babel

Leveraging scanner-js within an Angular2 environment

What is the best way to implement custom serialization for Date types in JSON.stringify()?

Converting a string into a Date in Typescript while disregarding the timezone

Discovering the number of items that have been filtered in isotope-layout using React and Typescript

Ways to dynamically generate a generic that expands a union class type

Tips for customizing the legend color in Angular-chart.js

Is there a way to use Regex to strip the Authorization header from the logging output

What is the best way to update the color of a label in a Mantine component?

Testing Jasmine with objects that contain optional properties

Unit testing Angular components can often uncover errors that would otherwise go unnoticed in production. One common

The functionality of the disabled button is malfunctioning in the Angular 6 framework

The proper method for referencing TypeScript compiled files with the outDir option

Chai is unable to differentiate between different class types

Using TypeScript in React, how can I implement automation to increment a number column in a datatable?