Typing issue in Tour of Heroes example for chapter 5

[rdettai]

In chapter 5 "Services" of the Tour of Heroes tutorial, you can find this example:

getHeroesSlowly(): Promise<Hero[]> {
  return new Promise<Hero[]>(resolve =>
    setTimeout(resolve, 2000)) // delay 2 seconds
    .then(() => this.getHeroes());
}

Not being familiar with Promises and TypeScript, this got me confused. How come the typing is done in the constructor with the <Hero[]> type argument? The first Promise constructed actually does not return this array, it is only the then statement that is indeed typed. So I believe the following syntax would make more sense:

getHeroesSlowly(): Promise<Hero[]> {
  return new Promise(resolve =>
    setTimeout(resolve, 2000)) // delay 2 seconds
    .then<Hero[]>(() => this.getHeroes());
}

Sorry, but I come from java where this could never get past the compiler !

[aluanhaddad]

@rdettai Your intuition is correct. The generic type passed to Promise.constructor is actually misleading. It is used to create a promise of the desired type so that the type is propagated through .then. Your approach is clearer as to intent, and is more idiomatic.
Personally, I would prefer to leverage type inference all the way throughout the method to avoid misleading and potentially unsafe type assertions.

export interface Hero {
  name: string;
  powers: string[];
}
@Injectable() export class Service {

  getHeroesSlowly() {
    return new Promise(resolve => {
          setTimeout(resolve, 2000);
      })
      .then<Hero[]>(() => this.getHeroes());
  }

  getHeroes(): Hero[] {
    return [{
      name: 'Wolverine',
      powers: [
        'Adamantium Claws', 
        'Mutant Healing'
      ]
    }];
  }
}

Letting the inference do more work leads to more type checking and more specific types.

[wardbell]

I beg to differ. The type-parameter passed to the Promise constructor is perfectly correct in all languages that support generics properly. It should work in Java too.

That said, the example code is horrible (which I am allowed to say because I wrote it :)).

In a PR #2991, I change it to the following:

  getHeroesSlowly(): Promise<Hero[]> {
    return new Promise(resolve => {
      // Simulate server latency with 2 second delay
      setTimeout(() => resolve(this.getHeroes()), 2000);
    });
  }

@aluanhaddad I like type inference too. Within the docs, our policy is to state public method return types explicitly on the method signature so that you can tell at a glance while reading the code what the method returns.

[aluanhaddad]

@wardbell that's fair since the IDE isn't there to serve up the signature in the example.
However, it leads people into the practice of placing these annotations. With generics this can be problematic because TypeScript's generics are unsafely covariant. So a Promise<void> will happily convert to a Promise<any> and mislead the caller into thinking they would get a result back.

[wardbell]

@aluanhaddad true (until TS 2.1 I think). I would hope that I didn't make that mistake. I also hope that anyone who sees explicit typing of Promise<any> or Promise<void> realizes that the returned value is uninteresting; what matters is that it resolves or errors.

Structural typing is not as safe as nominal typing ... by design. That's why we say that TypeScript provides "static typing" not "strict typing". It's still JavaScript after all. On balance, I'm happy with the compromises.

[aluanhaddad]

@wardbell The difference between structural and nominal typing is completely orthogonal to the notion of type safety, strictness, and staticness. It certainly has nothing to do with the issue in question.