3

I just recently did an npm update on my Aurelia CLI project using TypeScript in Visual Studio 2015. I'm using aurelia-fetch-client for making calls to my Web API (.NET Core) backend.

This is an example of the code that was previously compiling and running fine:

import { autoinject } from "aurelia-framework";
import { HttpClient, json } from "aurelia-fetch-client";
import { SupportedCultureInfo } from "../../model/Resources/SupportedCultureInfo";

@autoinject()
export class ResourceService {
    constructor(private http: HttpClient) {
    }

    getSupportedCultures(): Promise<SupportedCultureInfo[]> {
        return this.http.fetch("resource/cultures").then(response => response.json());
    }
}

Neither Visual Studio nor ReSharper provides any indication in the code editor UI that this will not compile, however after the recent update my build is now broken with this error:

TS2322: Type 'Promise<Response>' is not assignable to type 'Promise<SupportedCultureInfo[]>'

The only workaround I've found so far is to return Promise<any> instead. What I really want to do here though is return classes mapped from the JSON result and have the return type of the method be a strongly-typed Promise as well.

Does anyone know what has changed recently that could cause this? It's very frustrating.

UPDATE:

This is the code that I was able to get working:

import { autoinject } from "aurelia-framework";
import { HttpClient, json } from "aurelia-fetch-client";
import { SupportedCultureInfo } from "../../model/resources/SupportedCultureInfo";

@autoinject()
export class ResourceService {
    constructor(private http: HttpClient) {
    }

    getSupportedCultures(): Promise<SupportedCultureInfo[]> {
        return this.http.fetch("resource/cultures")
            .then(response => response.json())
            .then<SupportedCultureInfo[]>((data: any) => {
                const result = new Array<SupportedCultureInfo>();
                for (let i of data) {
                    const info = new SupportedCultureInfo();
                    info.cultureCode = i.cultureCode;
                    info.name = i.name;
                    info.isCurrentCulture = i.isCurrentCulture;
                    result.push(info);
                }

                return result;
            });
    }
}

I had to do two things that weren't immediately obvious:

  1. Use the generic overload of then() to specify the return type I want to use
  2. Explicitly declare any type for the JSON parameter in the second callback, otherwise the gulp transpiler thinks it's still typed as Response.
Sam
  • 6,167
  • 30
  • 39

1 Answers1

3

UPDATE:

I've accidentally hit Enter causing the comment to be posted unfinished. I'm unable to edit the comment so updating my answer as per the updated question.

Chaining Callbacks: If the API resource/cultures returns the response as SupportedCultureInfo[] and getSupportedCultures() just need to return the response as it is, then there's no need for that second callback. The answer I've posted previously would be sufficient.

I'm guessing a second callback is most likely required in either of these two cases (or for some other reason)

  1. The API returns a different type that has to be mapped to SupportedCultureInfo[]
  2. The API response requires any further processing before sending it back from getSupportedCultures()

If you require a second callback to process the response further then you should call the generic then<TResult> method while you're reading the response as json instead of at a later part in the callback chain.

Reason for reported error: In the updated code, the reason gulp transpiler treats data as type of Response is due to the fact that a non-generic then(response => response.json()) is being used which returns Promise<Response>.

Instead use then<SupportedCultureInfo[]>(response => response.json()) which would return Promise<SupportedCultureInfo[]> or then<any>(response => response.json()) which would return Promise<any>.

Using either then<SupportedCultureInfo[]>(response => response.json()) or then<any>(response => response.json()) would give you the data in the second callback as SupportedCultureInfo[] or any respectively.

getSupportedCultures(): Promise<SupportedCultureInfo[]> {
    return this.http.fetch("resource/cultures")
        .then<SupportedCultureInfo[]>(response => response.json())
        .then(data => {
                  // data will be of type SupportedCultureInfo[]
              });
}

As the method signature for then<TResult> is intact it should give a strongly typed data varaible.

Solution

The changes to typescript implies that we specify the return type as a type parameter to then<TResult> callback as shown below.

getSupportedCultures(): Promise<SupportedCultureInfo[]> {
    return this.http.fetch("resource/cultures").then<SupportedCultureInfo[]>(response => response.json());
}

Details:

I ran into the same situation when I did an npm update. Although my initial thoughts were to blame aurelia-fetch-client as well, I did some digging into the source code to contribute a fix for this issue. But, in my quest I found that typescript is the real culprit here.

The interface Promise<T> had some changes in the way then callback handles the return types. Now, the desired return type needs to be passed in as a type parameter TResult in then<TResult> callback.

Rohith
  • 56
  • 5
  • Thanks, that got me halfway there - the other thing I had to do was explicitly declare JSON arguments as any, otherwise the transpiler would think it was Response, see edit. – Sam Nov 29 '16 at 00:28
  • Hi @Sam, I don't think you need to do a mapping from data to result just to get a strongly typed result because the fact that you're able to do a for on data itself conveys that it's of an array type. – Rohith Nov 29 '16 at 03:05
  • The objects returned from response.json() are not instances of SupportedCultureInfo, they are just POJOs at runtime. They happen to have the same data members but that's not enforced at runtime because the type information has been erased. By mapping to classes, I'm ensuring that the caller gets actual instances of a given class, mainly so that they can call instance methods on that class. The POJOs won't have any instance methods. – Sam Nov 29 '16 at 05:57
  • Thanks for this post, I've just spent two hours banging my head with this. The typed overload of then() was the only fix I could find. – esmoore68 Feb 16 '17 at 15:23