Type "json" | undefined not satisfied by "json" in Angular HttpClient

Question

I'm scrutinizing the docs for HttpClient, focusing on the get(...) method. I've prepared the following sample:

const headers: HttpHeaders = new HttpHeaders();
const observe: HttpObserve = null;
const params: HttpParams = new HttpParams();
const reportProgress = false;
const responseType = "json";
const withCredentials = true;

const options = {
  headers, observe, params,
  reportProgress, responseType, withCredentials
};

this.http.get(url, options)

I get an error stating the following.

No overload matches this call.  
The last overload gave the following error.  
Argument of type '{ responseType: string; ... }'  
is not assignable to parameter of type '{ responseType?: "json" | undefined; ... }'.  
Types of property 'responseType' are incompatible.
Type 'string' is not assignable to type '"json" | undefined'.

It's pretty obvious what's the reported issue. However, I don't see how what I typed is in validation towards what is required. If I type undefined as the value for responseType, the compiler is satisfied. In fact, the elaborated code samples (number 7, 8 and 12 through 15) explicitly state that it's the syntax to be used.

How is my "json" not the required "json"?

Familial

Because responseType is typed as string, that's what the error message tells you. It's not typed as the string literal type "json". – Liddy

It should have been inferred as the literal type since TS 2.1, though - what version are you using? – Liddy

@Liddy My VSCode says v3.9.4 at the bottom. When I ran tsc --version, I got an error but it's likely due to being in the wrong directory. I trust VSC on this one. Also, I'm not entirely sure what you mean by literal type so I'll google it. I thought that a string literal type and a constant string were different names for the same concept. – Familial

typescriptlang.org/docs/handbook/… - "json" is a string but not all string are "json". – Liddy

@KonradViltersten: By literal type he means type json instead of string. One workaround could be const responseType = "json" as "json"; – Havstad

It works in 3.9.2 on the playground: typescriptlang.org/play/index.html#code/…. Could be a bug in 3.9.4, maybe see if anyone's reported it. – Liddy

@MichaelD prefer const responseType: "json" = "json"; - then the actual value gets checked (compare const foo = "bar" as "baz"). – Liddy

@MichaelD I feel a bit retarded now. Are you saying that my string should contain a valid JSON syntax (i.e. brackets, properties, colons and value, e.g. {a:1})? Also, as "json" felt unfamiliar to me. As far my competence reaches, there's no Json type/class in TS. Or is it som black magic (black magic to ignorant me, that is) saying that the type is whatever, where said whatever happens to be "json" sequence of characters? – Familial

@KonradViltersten no they're not saying that at all, just missing quotes from "json". If you don't know what as <type> means read up on type assertions. You really need to know TS basics to be effective in Angular. – Liddy

Oh I get it, it's because { responseType } widens to { responseType: string } - typescriptlang.org/play/index.html#code/…. – Liddy

@KonradViltersten: Not exactly. Think of string literal type (json here) with union types ("json" | "text" | ...) akin to enums. So the responseType should have the exact string "json". But for some reason (which I too don't understand yet), it's being inferred as type string in your case. So one solution would be to assert the type using the as <type> syntax or better as @Liddy suggested define the type before assigning the value: const responseType: "json" = "json";. – Havstad

@KonradViltersten it's literally on the "basic types" page... – Liddy

@MichaelD I must admit, I feel a weird satisfaction and relaxation of the mind when other developers whom I trust say things like "I too don't understand" as it provides me the notion of not being a single dumb dude on the block but actually hitting something that's at least a little bit confusing. I hate being the only confusee. :) – Familial

Answer 1

The HttpClient methods use string literal types for some of the options - rather than just declaring e.g. responseType as the generic string they provide the specific values it can take. So why does your options object not meet the type definition, given it has one of the accepted values?

The initial declaration:

const responseType = "json";

defines responseType as the string literal type "json"; it's a const, it can only ever have that single value. So far, so good. However, the object declaration:

const options = { responseType /* etc. */ };

gives options the type { responseType: string }, it widens the type of the attribute. It does this because objects are mutable, so you could change the value.

To fix this, you have several options; in no particular order:

• Inline the object creation:

   this.http.get(url, { responseType });
  

  This doesn't widen the type, because you can't assign a different value into an object you don't hold a reference to.

• Explicitly type the intermediate object:

   const options: { responseType: "json" } = { ... };
  

• Use a const assertion on the object:

   const options = { responseType } as const;  // or = <const>{...};
  

  This tells the compiler you aren't going to change the values and gives options the type { readonly responseType: "json" }.

• Use a const assertion on the string (suggested by Michael D):

  const responseType = "json" as const;  // or = <const>"json";
  

  This one's a bit weird, because the type of responseType is still "json", as it was originally. However this creates a "const context" in which that type is non-widening, so the resulting type of options is { responseType: "json" } (not readonly as above, but you can only assign that one value to it).

Here is a playground showing the various options for options: TypeScript Playground.

Liddy

This is rather interesting. I'd also add the type cast solution: <const>'json'. – Havstad

@MichaelD that does seem to work, const responseType = <const>"json" (or "json" as const to use the syntax in the answer), but I don't understand why so I don't really want to add it - the type of responseType doesn't change, it's still "json", but that <const> seems to impact the object creation too, that metadata somehow stays with the value. It makes the options type { responseType: "json" }, which isn't readonly like as const on the object but can still only take that one value. – Liddy

@MichaelD alright I figured it out and added it, thanks! – Liddy