Avoid insecurely assigning an any value in TypeScript

Question

Avoid insecurely assigning an any value in TypeScript

Take a look at this code snippet:

const defaultState = () => {
  return {
    profile: {
      id: '',
      displayName: '',
      givenName: '',
    },
    photo: '',
  }
}

const state = reactive(defaultState())

export const setGraphProfile = async () => {
  const response = await getGraphProfile()
  state.profile = { ...defaultState().profile, ...response.data }
}

An ESLint warning is triggered by this code:

@typescript-eslint/no-unsafe-assignment: Unsafe assignment of an any value.

This warning indicates that the properties in response.data may not match those of the profile. The return type of getGraphProfile is

Promise<AxiosResponse<any>>

. To suppress the ESLint warning, you can simply disable it like this:

// eslint-disable-next-line @typescript-eslint/no-unsafe-assignment
state.profile = { ...defaultState().profile, ...response.data }

Queries:

How can we structure the data in the Promise getGraphProfile to ensure compatibility? One option is to create a TS interface, but this would result in redundant code with the object defaultState().profile
Why does TypeScript not raise an issue with this code while the linter does? Shouldn't they both be aligned?

The implementations:

const callGraph = (
  url: string,
  token: string,
  axiosConfig?: AxiosRequestConfig
) => {
  const params: AxiosRequestConfig = {
    method: 'GET',
    url: url,
    headers: { Authorization: `Bearer ${token}` },
  }
  return axios({ ...params, ...axiosConfig })
}

const getGraphDetails = async (
  uri: string,
  scopes: string[],
  axiosConfig?: AxiosRequestConfig
) => {
  try {
    const response = await getToken(scopes)
    if (response && response.accessToken) {
      return callGraph(uri, response.accessToken, axiosConfig)
    } else {
      throw new Error('We could not get a token because of page redirect')
    }
  } catch (error) {
    throw new Error(`We could not get a token: ${error}`)
  }
}

export const getGraphProfile = async () => {
  try {
    return await getGraphDetails(
      config.resources.msGraphProfile.uri,
      config.resources.msGraphProfile.scopes
    )
  } catch (error) {
    throw new Error(`Failed retrieving the graph profile: ${error}`)
  }
}

export const getGraphPhoto = async () => {
  try {
    const response = await getGraphDetails(
      config.resources.msGraphPhoto.uri,
      config.resources.msGraphPhoto.scopes,
      { responseType: 'arraybuffer' }
    )
    if (!(response && response.data)) {
      return ''
    }
    const imageBase64 = new Buffer(response.data, 'binary').toString('base64')
    // eslint-disable-next-line @typescript-eslint/no-unsafe-member-access
    return `data:${response.headers['content-type']};base64, ${imageBase64}`
  } catch (error) {
    throw new Error(`Failed retrieving the graph photo: ${error}`)
  }
}

javascript typescript eslint

Answer 1

Answer №1

TypeScript doesn't output warnings, only errors. According to TS, the assignment of 'any' is considered valid. However, a linter can provide additional support in this area.

No need to replicate your interface. Utilize TypeScript's 'ReturnType' to determine the type of the 'profile' object in your 'defaultState' method:

type IProfile = ReturnType<typeof defaultState>["profile"]

The code above showcases three outstanding TypeScript features:

'ReturnType' for inferring function return types
'typeof' for deducing interfaces from object instances
Using '["profile"]' to identify the type of a specific property within an interface

Make your 'callGraph' function generic now:

function callGraph<T>(url: string, token: string, axiosConfig?: AxiosRequestConfig) {
  const params: AxiosRequestConfig = {
    method: 'GET',
    url: url,
    headers: { Authorization: `Bearer ${token}` },
  }
  return axios.request<T>({ ...params, ...axiosConfig })
}

Update the 'callGraph' invocation within your 'getGraphDetails' function as follows:

...
  if (response && response.accessToken) {
    return callGraph<IProfile>(uri, response.accessToken, axiosConfig)
  }
...

Your graph calls are now correctly typed without needing to duplicate your profile definition. Instead, leverage TypeScript's fantastic type inference capabilities to "read your interface" from the function's return type.

Answer 2

TypeScript doesn't output warnings, only errors. According to TS, the assignment of 'any' is considered valid. However, a linter can provide additional support in this area.

No need to replicate your interface. Utilize TypeScript's 'ReturnType' to determine the type of the 'profile' object in your 'defaultState' method:

type IProfile = ReturnType<typeof defaultState>["profile"]

The code above showcases three outstanding TypeScript features:

'ReturnType' for inferring function return types
'typeof' for deducing interfaces from object instances
Using '["profile"]' to identify the type of a specific property within an interface

Make your 'callGraph' function generic now:

function callGraph<T>(url: string, token: string, axiosConfig?: AxiosRequestConfig) {
  const params: AxiosRequestConfig = {
    method: 'GET',
    url: url,
    headers: { Authorization: `Bearer ${token}` },
  }
  return axios.request<T>({ ...params, ...axiosConfig })
}

Update the 'callGraph' invocation within your 'getGraphDetails' function as follows:

...
  if (response && response.accessToken) {
    return callGraph<IProfile>(uri, response.accessToken, axiosConfig)
  }
...

Your graph calls are now correctly typed without needing to duplicate your profile definition. Instead, leverage TypeScript's fantastic type inference capabilities to "read your interface" from the function's return type.

Answer 3

Answer №2

Let's tackle your inquiries in reverse order:

Why does TypeScript not flag any issues with this code while the linter does? Shouldn't they both be consistent?

In TypeScript, using type any allows you to assign it to any other type without restrictions. This essentially removes type safety from that specific part of the code. For instance:

const foo: number = 'hello' as any // TypeScript doesn't complain about this

The purpose of the eslint rule is probably to identify instances where assigning a value of type any may not be intentional. It is interesting to note that TypeScript provides the compiler option noImplicitAny which serves a similar purpose.

How can we structure the data in the Promise returned by getGraphProfile to align with the expected format? Creating a TypeScript interface would lead to duplicating code with object defaultState().profile

There are several ways to address this issue. A straightforward solution would involve typing the return value of getGraphDetails:

type GraphDetailsPayload = {
  id: string,
  displayName: string,
  givenName: string,
}

export const getGraphProfile = async (): Promise<GraphDetailsPayload> => {
  ...
}

However, it is generally recommended to define the data at a lower level, such as within the callGraph function:

const callGraph = (
  url: string,
  token: string,
  axiosConfig?: AxiosRequestConfig
): Promise<GraphDetailsPayload> => {
  // implementation details here
}

By structuring it this way, the return value of callGraph is explicitly typed, allowing TypeScript to infer the types for getGraphDetails and getGraphProfile as they ultimately rely on the API response.

Alternatively, considering you use Axios, its TypeScript definition could allow for a more concise approach:

const callGraph = (
  url: string,
  token: string,
  axiosConfig?: AxiosRequestConfig
) => {
  // axios request details here
  return axios<GraphDetailsPayload>({ ...params, ...axiosConfig })
}

In this scenario, the explicit

Promise<GraphDetailsPayload>

return type is omitted, and instead, the GraphDetailsPayload type is directly provided to the axios function using generics. This demonstrates the usage of generics, often encountered when working with TypeScript libraries and functions.

Answer 4

Let's tackle your inquiries in reverse order:

Why does TypeScript not flag any issues with this code while the linter does? Shouldn't they both be consistent?

In TypeScript, using type any allows you to assign it to any other type without restrictions. This essentially removes type safety from that specific part of the code. For instance:

const foo: number = 'hello' as any // TypeScript doesn't complain about this

The purpose of the eslint rule is probably to identify instances where assigning a value of type any may not be intentional. It is interesting to note that TypeScript provides the compiler option noImplicitAny which serves a similar purpose.

How can we structure the data in the Promise returned by getGraphProfile to align with the expected format? Creating a TypeScript interface would lead to duplicating code with object defaultState().profile

There are several ways to address this issue. A straightforward solution would involve typing the return value of getGraphDetails:

type GraphDetailsPayload = {
  id: string,
  displayName: string,
  givenName: string,
}

export const getGraphProfile = async (): Promise<GraphDetailsPayload> => {
  ...
}

However, it is generally recommended to define the data at a lower level, such as within the callGraph function:

const callGraph = (
  url: string,
  token: string,
  axiosConfig?: AxiosRequestConfig
): Promise<GraphDetailsPayload> => {
  // implementation details here
}

By structuring it this way, the return value of callGraph is explicitly typed, allowing TypeScript to infer the types for getGraphDetails and getGraphProfile as they ultimately rely on the API response.

Alternatively, considering you use Axios, its TypeScript definition could allow for a more concise approach:

const callGraph = (
  url: string,
  token: string,
  axiosConfig?: AxiosRequestConfig
) => {
  // axios request details here
  return axios<GraphDetailsPayload>({ ...params, ...axiosConfig })
}

In this scenario, the explicit

Promise<GraphDetailsPayload>

return type is omitted, and instead, the GraphDetailsPayload type is directly provided to the axios function using generics. This demonstrates the usage of generics, often encountered when working with TypeScript libraries and functions.

Avoid insecurely assigning an any value in TypeScript

Queries:

The implementations:

Answer №1

Answer №2

Similar questions

Utilizing Gulp locally without the need for global installation or referencing the bin js file

Tips for activating this effect even when the window is resized during page scrolling

Try rotating a triangle in 3D using either CSS or JavaScript

Having trouble resolving the dependency injection for stripe-angular

Managing code requiring document.title in Next.js with Static Site Generation (SSG)

The logic behind regular expressions

Multiple jQuery load() requests are being triggered by calling it from within the ajaxComplete() callback

What is the best way to utilize yarn in order to install a GitHub package that utilizes TypeScript and has not yet been compiled?

Executing the AngularJS nested controller only once

Typescript: Defining the correct return type for resolved parameters in promises

How can I use Angular to dynamically open a video that corresponds to a clicked image?

Prevent rendering a file in node.js using ejs if it cannot be found

Find the sum of every combination of numbers in the array

Obtain specific fields from a multidimensional array object using lodash

Using jQuery.ajax to manage caching and manipulating timestamps

Issue encountered in Loopback 4: Error with @repository dependency injection (TypeError: Undefined property 'findOne')

Exploring the relationship between Typescript, RxJS, Ajax, undefined values

Obtaining a specific data point from a JSON object sourced from Twitter

What are the steps to fixing the TS2722 error that says you cannot call a possibly 'undefined' object?

Creating a nested list component using an array of objects