Interest in TypeScript?

[Bouke]

Hello! I use your addon and really appreciate it. I'm also participating in this quest issue to add TypeScript support throughout the Ember.js ecosystem. (This will benefit to anyone who uses your addon, not just TypeScript users!) Are you interested in either converting the addon to use TypeScript itself, or in adding type definitions? I already have worked out most of the type definitions in my own project, which I could provide through DefinitelyTyped instead. Thanks!

[alexlafroscia]

Hmm, yeah, that would be interesting.

I know almost nothing about TypeScript though, or the pitfalls of converting an Ember addon.

Which would you suggest? Providing a type definition or just converting the addon over?

[Bouke]

The easiest starting point would be to add the type definitions. Converting the addon over requires a substantial amount of time, whereas the quickest gains (for users) would be provided with the typings already. If you're interested I can have a go at a PR for adding those typings to this repo?

[alexlafroscia]

Sure thing. Would TypeScript users just "magically" get type information with the definition being part of the repo?

Also, is there a process around ensuring the types are up-to-date? My concern with external type definitions is only that it becomes something to remember whenever the API changes.

OTOH this is really not much an issue since this addon will likely never see a major API change; I pretty actively encourage people to avoid this addon and use ember-fetch instead.

[chriskrycho]

👋 TS users will just get type info with the definition living in the repository. Even better, having them ship with the addon means that JS users will get code completion and any documentation attached to the type definitions if their editor supports it (and everything from Vim to IntelliJ idea does!). The ember-cli-typescript team will be happy to help check the type definitions and make sur ethey’re right!

[alexlafroscia]

Sweet. Let's do this, then! Let me know if there's anything on my end that can be done to improve the TypeScript experience.

[alexlafroscia]

I've been converting a bunch of my addons to TypeScript lately and enjoying it, so I'm actually looking into just converting the addon entirely instead of just adding a type definition.

[alexlafroscia]

@bcardarella @chriskrycho What is the standard around your application depending on third-party types?

ember-ajax has some type definitions that depend on @types/node and @types/jquery. Should those be listed under dependencies? devDependencies? Or is there some other way to do it?

[chriskrycho]

They should normally be devDependencies.

[alexlafroscia]

👍 Excellent. Have been making some good progress on this and learning a lot about TypeScript in the process!

[alexlafroscia]

@Bouke Can you share the type definition that you created with me? It might be helpful in a few places that I'm struggling right now.

I'm specifically struggling to correctly convert the custom Promise class we have:

https://github.com/ember-cli/ember-ajax/blob/b96b65fe49e1d587fb29b6c19e9f5d6481dbb9f1/addon/-private/promise.js

I can't find a way to extend Promise, add the property to the resulting object, and satisfy the TS compiler.

Edit:

By copying the @types/rsvp code a bit I was able to define it like this, without issues:

import { Promise } from 'rsvp';

/**
 * AJAX Promise
 *
 * Sub-class of RSVP Promise that passes the XHR property on to the
 * child promise
 *
 * @extends RSVP.Promise
 * @private
 */
export default class AJAXPromise<T> extends Promise<T> {
  xhr?: XMLHttpRequest;

  /**
   * Overriding `.then` to add XHR to child promise
   *
   * @public
   * @return {AJAXPromise} child promise
   */
  then<TResult1 = T, TResult2 = never>(
    onFulfilled?:
      | ((value: T) => TResult1 | PromiseLike<TResult1>)
      | undefined
      | null,
    onRejected?:
      | ((reason: any) => TResult2 | PromiseLike<TResult2>)
      | undefined
      | null,
    label?: string
  ): AJAXPromise<TResult1 | TResult2> {
    const child = super.then(onFulfilled, onRejected, label);

    (child as AJAXPromise<TResult1 | TResult2>).xhr = this.xhr;

    return child;
  }
}

But this seems way more verbose than it should need to be...

[alexlafroscia]

Just for information about the progress here, I've been working on the TypeScript conversion and #355 at the same time. I want to make sure that the FastBoot test is in place first, since I need to ensure that moving to TypeScript doesn't break anything and we have never had any real test coverage around the FastBoot support.

[alexlafroscia]

Discovered an RSVP typings bug in the process 🙃 DefinitelyTyped/DefinitelyTyped#26640

[alexlafroscia]

Rather than continuing here, maybe I can ask some questions in #356 to get clarification on the "right way" to do certain things.

An updated version of the promise.ts class can bee sound on the PR linked above.