With the release of Typescript 3.4, a new feature called the 'const' assertion was introduced.

This allows you to prevent literal types (such as 'orange' or 'red') from being automatically converted to type

string</code using the so-called <code>const

For example, you can now write:

let fruit = 'orange' as const;  // or...
let fruit = <const> 'orange';

These statements ensure that the value does not get converted into a string, addressing an issue frequently encountered.

You also have the option to apply this on an entire object:

let animals = [ { species: 'dog' }, { species: 'cat' } ] as const;

type firstAnimal = (typeof animals)[0]['species'];  // results in string literal 'dog'

Pro Tip: Another handy use of <const> false or <const> true is when representing boolean values that must strictly be either true or false. This can prove beneficial in scenarios like discriminated unions. Keep an eye out for opportunities to leverage this technique.

Here's what happens:

export type Fruit = "Orange" | "Apple" | "Banana"

By writing this code, you are defining a type named Fruit that can only hold the values of "Orange", "Apple", or "Banana". This type is considered to be an extension of the type String, allowing it to be assigned as a value of String. However, keep in mind that String does not extend "Orange" | "Apple" | "Banana", so it cannot be assigned to it. String is more general and can represent any string value.

Now, let's consider this scenario:

export type Fruit = "Orange" | "Apple" | "Banana"

const myString = "Banana";

const myFruit: Fruit = myString;

Surprisingly, this works perfectly fine. Why? Because the specific type of myString in this context is "Banana". In essence, "Banana" itself serves as the type, which extends the generic String type and thus can be assigned to it. Furthermore, a type is said to extend a Union Type when it extends at least one of its components. Here, "Banana" (as a type) extends "Orange" | "Apple" | "Banana" by virtue of extending one of its constituent elements. Therefore, "Banana" can indeed be assigned to "Orange" | "Apple" | "Banana" or the type Fruit.

There are numerous scenarios that can trigger this specific error. In the instance mentioned, a value was explicitly defined as a string. It is possible that this originated from a dropdown menu, web service, or direct JSON string.

In such situations, the only resolution is to perform a simple cast like <Fruit> fruitString or fruitString as Fruit (refer to other responses). There is no room for improvement during compilation in this case. [Note: Refer to my previous response regarding <const>] !

However, encountering the same error becomes quite easy when utilizing constants in your code that were never supposed to be of string type. My approach delves into this alternate scenario:

Firstly: Why do 'magic' string constants often outshine enums?

• I prefer the concise and 'javascripty' appearance of a string constant over an enum
• It makes more sense if the component you're working with already employs string constants
• The need to import an 'enum type' just to access an enumeration value could pose challenges in itself
• Whatever I implement must be compile-safe - any addition or removal of a valid value from the union type, or typos, should trigger a compile error

Luckily, defining:

export type FieldErrorType = 'none' | 'missing' | 'invalid'

...essentially creates a union of types where 'missing' is considered a type!

I frequently encounter the 'not assignable' error when a string like 'banana' is present in my typescript, confusing the compiler which interprets it as a string when in reality, it should be of type banana. The effectiveness of the compiler's interpretation will vary based on your code structure.

Here's an instance where I encountered this error today:

// results in the error 'string is not assignable to type FieldErrorType'
fieldErrors: [ { fieldName: 'number', error: 'invalid' } ]

Upon realizing that 'invalid' or 'banana' could represent either a type or a string, I opted to assert a string into that type. Essentially, I would cast it to its original form, informing the compiler that I do not intend for this to remain a string!

// hence, this eliminates the error without importing the union type
fieldErrors: [ { fieldName: 'number', error: <'invalid'> 'invalid' } ]

Why not simply 'cast' to FieldErrorType (or Fruit)

// why isn't this advisable?
fieldErrors: [ { fieldName: 'number', error: <FieldErrorType> 'invalid' } ]

This method lacks compile-time safety:

 <FieldErrorType> 'invalidddd';  // COMPILER ACCEPTS THIS - NOT IDEAL!
 <FieldErrorType> 'dog';         // COMPILER ACCEPTS THIS - NOT IDEAL!
 'dog' as FieldErrorType;        // COMPILER ACCEPTS THIS - NOT IDEAL!

Why? Because in typescript, <FieldErrorType> serves as an assertion, indicating that a dog belongs to FieldErrorType! The compiler doesn't object to this!

However, by executing the following approach, the compiler converts the string to a type

 <'invalid'> 'invalid';     // THIS IS FINE - APPROPRIATE
 <'banana'> 'banana';       // THIS IS FINE - APPROPRIATE
 <'invalid'> 'invalidddd';  // ERRONEOUS       - APPROPRIATE
 <'dog'> 'dog';             // ERRONEOUS       - APPROPRIATE

Exercise caution to avoid careless errors like:

 <'banana'> 'banan';    // COULD LEAD TO RUNTIME ERROR - YOUR RESPONSIBILITY!

Another workaround involves casting the parent object:

My definitions stood as follows:

   export type FieldName = 'number' | 'expirationDate' | 'cvv';
   export type FieldError = 'none' | 'missing' | 'invalid';
   export type FieldErrorType = { field: FieldName, error: FieldError };

Suppose we face an error similar to this (the string not assignable error):

  fieldErrors: [ { field: 'number', error: 'invalid' } ]

We can assert the entire object as a FieldErrorType in this manner:

  fieldErrors: [ <FieldErrorType> { field: 'number', error: 'invalid' } ]

Thus, we avoid resorting to <'invalid'> 'invalid'.

Concerning potential typos - doesn't <FieldErrorType> merely serve to assert whatever appears on the right as that particular type? Not in this context - thankfully, the compiler WILL raise objections in instances where it deems impossibility:

  fieldErrors: [ <FieldErrorType> { field: 'number', error: 'dog' } ]

This may have been written a while ago, but I believe there could be an improved approach.

If you're looking for a way to ensure a string variable is limited to specific values, consider using enums.

Here's an example:

enum Fruit {
    Orange = "Orange",
    Apple  = "Apple",
    Banana = "Banana"
}

let myFruit: Fruit = Fruit.Banana;

By using enums, you can guarantee that myFruit will always hold the value "Banana" or any other predefined option within the enum. This technique is beneficial for various scenarios, such as categorizing similar values or translating user-friendly inputs into machine-readable formats with strict validation by the compiler.

When using spreading in arrays, it's possible for errors to be thrown in a slightly misleading way:

export type Fruit = "Orange" | "Apple" | "Banana"
export type FruitArray = Fruit[];

const someFruits= ["Banana"];

const workingFruits: FruitArray = ["Orange", "Apple"]; // This works

// However, even with Orange and Apple included, an error occurs: Type 'string' is not assignable to type Fruit
const brokenAllFruits: FruitArray = [...someFruits, "Orange", "Apple"]; 

// Solution is to use const in the spread array
const someConstFruits= ["Banana" as const];
const workingAllFruits: FruitArray = [...someConstFruits, "Orange", "Apple"]; // This works

Although all of the answers above are valid, there are instances where a String Literal Type is nested within another complex type. Let's consider the example below:

  // in foo.ts
  export type ToolbarTheme = {
    size: 'large' | 'small',
  };

  // in bar.ts
  import { ToolbarTheme } from './foo.ts';
  function useToolbarTheme(theme: ToolbarTheme) {/* ... */}

  // In this scenario, you will encounter the error message: 
  // Type 'string' is not assignable to type '"small" | "large"'.ts(2322)
  ['large', 'small'].forEach(size => (
    useToolbarTheme({ size })
  ));

There are multiple solutions available to address this issue, each with its own suitable applications.

1) The first solution involves defining a separate type for the size and exporting it from foo.ts. This approach is beneficial when working specifically with the size parameter. For instance, if you have a function that takes or returns a parameter of type size and requires typing.

  // in foo.ts
  export type ToolbarThemeSize = 'large' | 'small';
  export type ToolbarTheme = {
    size: ToolbarThemeSize
  };

  // in bar.ts
  import { ToolbarTheme, ToolbarThemeSize } from './foo.ts';
  function useToolbarTheme(theme: ToolbarTheme) {/* ... */}
  function getToolbarSize(): ToolbarThemeSize  {/* ... */}

  ['large', 'small'].forEach(size => (
    useToolbarTheme({ size: size as ToolbarThemeSize })
  ));

2) The second option is to simply cast it to the type ToolbarTheme. In this case, there is no need to expose the internal structure of ToolbarTheme if not required.

  // in foo.ts
  export type ToolbarTheme = {
    size: 'large' | 'small'
  };

  // in bar.ts
  import { ToolbarTheme } from './foo.ts';
  function useToolbarTheme(theme: ToolbarTheme) {/* ... */}

  ['large', 'small'].forEach(size => (
    useToolbarTheme({ size } as ToolbarTheme)
  ));

I encountered a similar problem while passing props to a React Component.

Cause:

The type inference on myArray was not functioning correctly

https://codesandbox.io/s/type-string-issue-fixed-z9jth?file=/src/App.tsx

A big shoutout to Brady from Reactiflux for providing assistance with resolving this issue.

When simulating data, such as when casting to a dropdownvalue[], it is recommended to structure it as an array of objects containing value and display properties.

For example:

[{'value': 'test1', 'display1': 'test display'},{'value': 'test2', 'display': 'test display2'},]

Even though this question is tagged Angular, it actually doesn't have much to do with Angular. However, there is a specific case within Angular where you might encounter this error unexpectedly.

• The error may occur if you have disabled strictNullInputTypes
• It can also happen if you use a literal type like Fruit as an @Input()
• When you attempt to pass 'Orange' to an input and it is interpreted as a string.

This issue will be resolved in Angular 13.1.

https://github.com/angular/angular/pull/38305

If you are dealing with classes, there are multiple ways to approach it:

Let's consider a hypothetical model:

type Drink = 'Coffee' | 'Tea';

interface ClassWithDrink {
  drink: Drink;
}

Now, let's create a class that implements this model in three different ways:

class BeverageClass implements ClassWithDrink {
  // option 1
  drink = 'Coffee' as const;

  // option 2
  drink = <const>'Coffee';
  
  // option 3
  readonly drink = 'Coffee';
}

When dealing with models, the issue of constant alerts kept arising. My solution was to wrap the value in curly brackets like this: tabIndex={-1}