What is the reason behind angular 4.3's httpclient returning Object instead of any?

Question

What is the reason behind angular 4.3's httpclient returning Object instead of any?

The Angular 4.3 update introduces the new HttpClient class, which appears to return Object instead of any as the default type.

Is there a specific reason for this decision, especially considering the TypeScript documentation advises against using types like Number, String, Boolean, or Object?

Don’t ever use the types Number, String, Boolean, or Object. These types refer to non-primitive boxed objects that are almost never used appropriately in JavaScript code.

https://www.typescriptlang.org/docs/handbook/declaration-files/do-s-and-don-ts.html

While I understand that I can specify my own return type using:

this.httpService.get<any>('/api1').subscribe(Data => {console.log(Data.Value1)});

It would seem more convenient to have any as the default. I know I can define a specific type for the data being returned, but using any would make it more versatile.

I was considering extending the HttpClient class and overriding the methods to return any, but wanted to check if there was something important I might have overlooked.

angular typescript

Answer 1

Answer №1

The main focus in boxed objects in JavaScript code that are rarely used correctly lies on the word rarely.

As mentioned in this response, a JSON document can take any form except for undefined and symbol, making Object a better choice than any.

The distinction between any and Object is outlined in the manual:

The any type is a powerful tool for working with existing JavaScript code, allowing for incremental use of type-checking during compilation. While you might think that Object serves a similar purpose, it only permits assignment of values without enabling calls to arbitrary methods, even those that actually exist.

The use of any permits calling of arbitrary methods, including those that do not exist, which is not ideal.

A proper type for a JSON response would be

any[] | object | boolean | number | string | null

A more specific definition (as illustrated here, with the inclusion of null) is:

type JSONValue = boolean | number | string | null | JSONObject | JSONArray;

interface JSONObject {
    [x: string]: JSONValue;
}

interface JSONArray extends Array<JSONValue> { }

This is likely the recommended approach in HttpClient, as Object provides a more appropriate type than any despite being less precise.

Answer 2

The main focus in boxed objects in JavaScript code that are rarely used correctly lies on the word rarely.

As mentioned in this response, a JSON document can take any form except for undefined and symbol, making Object a better choice than any.

The distinction between any and Object is outlined in the manual:

The any type is a powerful tool for working with existing JavaScript code, allowing for incremental use of type-checking during compilation. While you might think that Object serves a similar purpose, it only permits assignment of values without enabling calls to arbitrary methods, even those that actually exist.

The use of any permits calling of arbitrary methods, including those that do not exist, which is not ideal.

A proper type for a JSON response would be

any[] | object | boolean | number | string | null

A more specific definition (as illustrated here, with the inclusion of null) is:

type JSONValue = boolean | number | string | null | JSONObject | JSONArray;

interface JSONObject {
    [x: string]: JSONValue;
}

interface JSONArray extends Array<JSONValue> { }

This is likely the recommended approach in HttpClient, as Object provides a more appropriate type than any despite being less precise.

Answer 3

Answer №2

Disclaimer: There are numerous overloads available with various return types, so my interpretation may be more extensive than necessary.

Although I have not come across specific evidence to support this, my speculation is that the reason could be because Object more precisely represents the type as it is stricter than any and inherently aligns with generic JavaScript object methods (refer to ). In my personal opinion, this change seems to be geared towards returning the response body as assumed JSON by default.

For a more comprehensive comparison between Object and any, please see this question here: TypeScript any vs Object

Additionally, there is a valuable article on HttpClient by Alligator.io available here: https://alligator.io/angular/httpclient-intro/

TLDR:

...One significant difference is that a JSON response is now expected by default, eliminating the need to explicitly parse the JSON response.

[Excess text omitted for brevity]

The HttpClient now defaults to returning the body of the response.

[Additional text removed]

If an alternative response other than JSON is expected, the expected response type can be specified using an object with the responseType key...

I highly recommend reading the entire article for more insights.

Answer 4

Disclaimer: There are numerous overloads available with various return types, so my interpretation may be more extensive than necessary.

Although I have not come across specific evidence to support this, my speculation is that the reason could be because Object more precisely represents the type as it is stricter than any and inherently aligns with generic JavaScript object methods (refer to ). In my personal opinion, this change seems to be geared towards returning the response body as assumed JSON by default.

For a more comprehensive comparison between Object and any, please see this question here: TypeScript any vs Object

Additionally, there is a valuable article on HttpClient by Alligator.io available here: https://alligator.io/angular/httpclient-intro/

TLDR:

...One significant difference is that a JSON response is now expected by default, eliminating the need to explicitly parse the JSON response.

[Excess text omitted for brevity]

The HttpClient now defaults to returning the body of the response.

[Additional text removed]

If an alternative response other than JSON is expected, the expected response type can be specified using an object with the responseType key...

I highly recommend reading the entire article for more insights.

What is the reason behind angular 4.3's httpclient returning Object instead of any?

Answer №1

Answer №2

Similar questions

Is your Angular 2 routing failing to work properly after a page refresh or reload when using gulp?

I'm curious if there's a method to ensure that the content within a mat-card stays responsive

Ways to bypass certificate verification

Clicking on an icon to initiate rotation (Material UI)

Issue with updating Angular list reference when deleting an item

Is it possible to upload an image-containing object to Mongodb with the help of Node.js?

Is it possible to pass additional arguments to setState other than prevState and props?

Implementing serialization and deserialization functionality in Typescript for classes containing nested maps

Using the useContext hook in a TypeScript class component: a step-by-step guide

Ways to implement pointer event styling within a span element

Best Practices for Implementing Redux Prop Types in Typescript React Components to Eliminate TypeScript Warnings

How can a method be called from a sibling component in Angular when it is bound through the <router-outlet>?

Angular Material table that uses a right-to-left direction for layout

Understanding Multiple Type Scenarios in React with Typescript

Custom attributes given to Stencil web components in Vite/Vue3 will not trigger any reactions

Is it possible to create a TypeScript generic type that transforms a Record into a type by utilizing the `as const` keyword?

Uh-oh! A circular dependency has been detected in the Dependency Injection for UserService. Let's untangle this web and fix the issue!

Angular 6 and the intricacies of nested ternary conditions

Angular example of Typeahead feature is sending a blank parameter to the backend server

What is the reason behind the sudden red coloring of parentheses in Visual Studio Code while typing in TypeScript?