Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PromiseProxyMixin uses RSVP.Promise which is incompatible with native Promises #341

Closed
boris-petrov opened this issue Oct 15, 2018 · 3 comments

Comments

@boris-petrov
Copy link

We discussed this in these two comments - here and here.

The problem is that PromiseProxyMixin uses RSVP.Promise in its type definition which makes it impossible to work with in TypeScript using native promises. And because Ember.js will be moving away from using RSVP at some point, this has to be figured out.

@chriskrycho
Copy link
Member

In the typings we've written, we've made a point to capture what the types actually are, and so long as Ember is using RSVP, we want the types to model that accurately (so we won't be changing them any time soon!).

It's often possible to use PromiseLike<T> instead of Promise<T> in your types, thought that doesn't solve behavior around async or await. It's also fine to do a type-cast: as Promise. RSVP.Promise is (by definition of its conformance to the A+ Promises spec) a strict superset of the native Promise type, and so will work for type purposes as a native Promise. In short, you should be able use an RSVP.Promise anywhere native Promise is desired, but not necessarily vice versa.

@mike-north
Copy link
Contributor

mike-north commented Oct 16, 2018 via email

@chriskrycho
Copy link
Member

This has largely been resolved by way of a few changes:

  1. We improved the types in this space (esp. for RSVP’s Promise compatibility) over time as TS afforded it.
  2. We changed how we represent mixins, especially in Ember's stable types.
  3. The Ember ecosystem has almost entirely moved away from PromiseProxyMixin, and it is in a position that it could be deprecated with effectively no churn.

Closing this accordingly!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants