What is the importance of having the same data type for the searchElement in the argument for Array.prototype.includes()?

Question

What is the importance of having the same data type for the searchElement in the argument for Array.prototype.includes()?

Is there an issue with my settings or is this a feature of TypeScript? Consider the code snippet below:

type AllowedChars = 'x' | 'y' | 'z';
const exampleArr: AllowedChars[] = ['x', 'y', 'z'];

function checkKey(e: KeyboardEvent) { 
    if (exampleArr.includes(e.key)) { // <-- here
        // ...
    } 
}

The TypeScript compiler displays an error that says

Argument of type 'string' is not assignable to parameter of type 'AllowedChars'

. But where am I assigning a value? The use of Array.prototype.includes only returns a boolean without any assignment. One way to silence the error is by using type assertion, such as:

if (exampleArr.includes(e.key as AllowedChars)) {}

But why is this considered correct when user input could be anything? It's puzzling why a function like Array.prototype.includes(), designed to check if an element exists in an array, needs to have knowledge about the expected input type.

This is the content of my tsconfig.json file (TypeScript version 3.1.3):

 {
    "compilerOptions": {
      "target": "esnext",
      "moduleResolution": "node",
      "allowJs": true,
      "noEmit": true,
      "strict": true,
      "isolatedModules": true,
      "esModuleInterop": true,
      "jsx": "preserve",
    },
    "include": [
      "src"
    ],
    "exclude": [
      "node_modules",
      "**/__tests__/**"
    ]
  }

If you have any insights, your help would be greatly appreciated!

javascript typescript

Answer 1

Answer №1

For a comprehensive discussion on Array.prototype.includes() and supertypes, please refer to microsoft/TypeScript#26255.

While technically safe to allow the searchElement parameter in Array<T>.includes() to be a supertype of T, the standard TypeScript library declaration assumes it as just T. In most cases, this assumption is valid as comparing completely unrelated types is usually not intended. However, in your case, the types are related.

There are multiple ways to address this issue. The assertion you've made might not be entirely correct since you are asserting that a string is an AllowedChars, which may not always hold true. Although it may work functionally, there could be a sense of discomfort about it.

An alternative approach is to locally override the standard library through declaration merging to accept supertypes. This method involves using conditional types to emulate a supertype constraint:

// remove "declare global" if you are writing your code in global scope to begin with
declare global {
  interface Array<T> {
    includes<U extends (T extends U ? unknown : never)>(
      searchElement: U, fromIndex?: number): boolean;
  }
}

Your original code can then operate smoothly:

if (exampleArr.includes(e.key)) {} // okay
// call to includes inspects as
// (method) Array<AllowedChars>.includes<string>(
//    searchElement: string, fromIndex?: number | undefined): boolean (+1 overload)

This modification prevents the comparison of entirely unrelated types:

if (exampleArr.includes(123)) {} // error
// Argument of type '123' is not assignable to parameter of type 'AllowedChars'.

A simpler yet accurate solution is broadening the type of exampleArr to readonly string[]:

const stringArr: readonly string[] = exampleArr; // no assertion
if (stringArr.includes(e.key)) {}  // okay

You can also achieve this more succinctly:

if ((exampleArr as readonly string[]).includes(e.key)) {} // okay

Widening to readonly string[] is acceptable, but caution is advised when widening to string[] as it may introduce risks due to covariant behavior in TypeScript. This is why using readonly is preferable.

Playground link to code

Answer 2

For a comprehensive discussion on Array.prototype.includes() and supertypes, please refer to microsoft/TypeScript#26255.

While technically safe to allow the searchElement parameter in Array<T>.includes() to be a supertype of T, the standard TypeScript library declaration assumes it as just T. In most cases, this assumption is valid as comparing completely unrelated types is usually not intended. However, in your case, the types are related.

There are multiple ways to address this issue. The assertion you've made might not be entirely correct since you are asserting that a string is an AllowedChars, which may not always hold true. Although it may work functionally, there could be a sense of discomfort about it.

An alternative approach is to locally override the standard library through declaration merging to accept supertypes. This method involves using conditional types to emulate a supertype constraint:

// remove "declare global" if you are writing your code in global scope to begin with
declare global {
  interface Array<T> {
    includes<U extends (T extends U ? unknown : never)>(
      searchElement: U, fromIndex?: number): boolean;
  }
}

Your original code can then operate smoothly:

if (exampleArr.includes(e.key)) {} // okay
// call to includes inspects as
// (method) Array<AllowedChars>.includes<string>(
//    searchElement: string, fromIndex?: number | undefined): boolean (+1 overload)

This modification prevents the comparison of entirely unrelated types:

if (exampleArr.includes(123)) {} // error
// Argument of type '123' is not assignable to parameter of type 'AllowedChars'.

A simpler yet accurate solution is broadening the type of exampleArr to readonly string[]:

const stringArr: readonly string[] = exampleArr; // no assertion
if (stringArr.includes(e.key)) {}  // okay

You can also achieve this more succinctly:

if ((exampleArr as readonly string[]).includes(e.key)) {} // okay

Widening to readonly string[] is acceptable, but caution is advised when widening to string[] as it may introduce risks due to covariant behavior in TypeScript. This is why using readonly is preferable.

Playground link to code

Answer 3

Answer №2

If you're looking at two distinct types, then it's natural for them to be different.

Picture this scenario:

type A = {paramA: string};
type B = {paramB: number};

const valuesA: A[] = [{paramA: 'whatever'}];
const valueB: B = {paramB: 5};

valuesA.includes(valueB); // This condition will always return false, so it doesn't really make sense

In this specific situation, the compiler interprets AllowedChars as a completely separate type from string. You need to "cast" the received string to AllowedChars.

But why is that necessary, I'm expecting user input which could be anything.

The compiler doesn't understand the purpose of the includes check. It only recognizes that they are different types and therefore shouldn't be compared directly.

Answer 4

If you're looking at two distinct types, then it's natural for them to be different.

Picture this scenario:

type A = {paramA: string};
type B = {paramB: number};

const valuesA: A[] = [{paramA: 'whatever'}];
const valueB: B = {paramB: 5};

valuesA.includes(valueB); // This condition will always return false, so it doesn't really make sense

In this specific situation, the compiler interprets AllowedChars as a completely separate type from string. You need to "cast" the received string to AllowedChars.

But why is that necessary, I'm expecting user input which could be anything.

The compiler doesn't understand the purpose of the includes check. It only recognizes that they are different types and therefore shouldn't be compared directly.

Answer 5

Answer №3

After some experimentation, I found that switching from using .includes to .some solved my issue. You can test it out in this TypeScript playground.

const FRUITS = ["apple", "banana", "orange"] as const
type Fruit = typeof FRUITS[number]

const isFruit = (value: string): value is Fruit =>
    FRUITS.some(fruit => fruit === value)

Answer 6

After some experimentation, I found that switching from using .includes to .some solved my issue. You can test it out in this TypeScript playground.

const FRUITS = ["apple", "banana", "orange"] as const
type Fruit = typeof FRUITS[number]

const isFruit = (value: string): value is Fruit =>
    FRUITS.some(fruit => fruit === value)

What is the importance of having the same data type for the searchElement in the argument for Array.prototype.includes()?

Answer №1

Answer №2

Answer №3

Similar questions

Upon attempting to fetch input by name, Puppeteer reported the error message: 'Node is not clickable or not an HTMLElement'

"Exploring the versatility of using variables in jquery's .css

Having trouble setting a value in a Vue.js variable

Creating customized JavaScript using jQuery for Drupal 7 Form API

Unusual layout in Next.js editor (VS Code)

A guide on extracting content from a PDF file with JavaScript

Utilize AJAX to fetch and display the response from a Node JS route directly onto an HTML page

How to use jQuery to locate and update the final parameter of a URL

Issue encountered: ENOENT - There is no file or directory located at the specified path for ... .steampath

Press on any two table cells to select their content, highlight it, and save their values in variables

Managing the placement of the expanded autocomplete input in Material-UI

Typescript's definition file includes imports that can result in errors

How to modify the content type in an Angular.js $http.delete request

Accessing props in react-native-testing-library and styled-components is not possible

The proper method for organizing a nested array object - an obstacle arises when attempting to sort the array

Crisscrossed JavaScript Object: recursion and "intricate" conversion (using lodash)

A guide on transferring a Vue component to a custom local library

Trouble with Component Lifecycle (ComponentDidMount) activation while switching tabs in TabBar?

Embed API allows users to showcase a variety of charts all on one page

Is there a way to ensure that the observer.next(something) received the value before executing observer.complete()?