Readers' Questions: "Why does Ember still use RSVP?"


#21

nice to have utility functions to make that shorter and clearer

In general, I agree, but (tiny bit of devil’s advocate here) I do wonder if that lends credence to the idea that Ember has a “lot to learn”. Cause even utility functions that make things nicer have to be learned before being used. I’ve used the above Promise.all pattern in a number of different frameworks, so it didn’t even occur to me to look for the hash functionality until I saw people discussing it in conversation.


#22

should we RFC to recommend not using RSVP, aside from utility functions like .hash?

Like, only warn about using promises without RSVP if the build target doesn’t natively have promises?


#23

I’m not suggesting it should be built into Ember, I’m suggesting that a tiny, plain-Javascript library can and should do the job. Any people would only add it if they want it.


#24

So it sounds like this is in the (near) future. Is there an RFC, a quest issue, and/or a pull request we can subscribe to to track this? Or is it already in canary/beta/stable? My biggest confusion around all of this is when the autorun will be embraced and how we can track when it happens.


#25

It’s already in 3.4 stable.


#27

The info in this thread is very interesting, thank you!

I am also interesting on it.

Then, it looks that from Ember 3.4; RSVP.Promise is not needed anymore, and we can start using native Promise instead (except for the RSVP non-spec API like hash, hashSettled...), is this correct or I misunderstood something?


#28

Yes, you should be able to use native Promise. If you find any problems with that please report them.


#29

@ef4 - please check out these 2 issues where I’ve given a few examples and reproductions of stuff that is broken:

Thanks!


#30

I replied on the first issue, but for folks watching this thread, the summary is: the native promise works fine, but you need to write tests that actually await all the asynchrony you care about. await render() just waits for render to happen. It doesn’t wait for Ember.run.later() to fire. But you can wait for that with await settled(), or you can use the waitFor or waitUntil functions from @ember/test-helpers to observe the results of your asynchrony.

RSVP.Promise sometimes lets you accidentally write sloppy tests that don’t say what they’re really waiting for. Conceptually, this is a leftover from the old-style tests that would “magically” do promise threading. The new-style test helpers are designed to let you explicitly wait for things instead.

Another way to state the problem is: getting “magic” waiting in tests is a non-standard feature of RSVP.Promise. But we don’t need to use that magic waiting anymore if we use the new-style test helpers.


#31

I have open an issue suggesting to remove RSVP from the latest docs.


#32

@ef4 using native promise I still don’t have to worry about the loop running on tests, right?


#33

This looks even better:

async model() {
  let [stuff, otherStuff] = await Promise.all([
    this.store.findAll('stuff'),
    this.store.findAll('otherStuff')
  ]);

  return { stuff, otherStuff };
}

There’s no need for Promise hash. The vanilla JS is good enough.


#34

Oh awesome! I somehow missed this! You just made my day :smiley:

My understanding is that the autorun assertion was the main blocker for using async/await in app code. Assuming that my application has all its test waiters setup correctly, am I now ok to use async and await in my application’s routes and actions? (Assuming 3.4 / Drop autorun assertion #16797)

PS: Sorry for bumping an old thread! I figured this was the best place to ask.


#35

@ryanto I think so, I created another post to make this info more discoverable: Can `async` and `await` be used in application code?


#36

babel compiles async/await to use native Promise with the regenerator runtime and there’s no way to easily customize it to use RSVP.Promise directly through the babel plugin.

If the target browsers all have native Promise you don’t need to worry, however, to support old browsers we need to add polyfills. babel.includePolyfill is huge, so it’s not ideal to include this wholesale.

The best solution so far I think is

Addons cannot use ember-cli-babel-polyfills unless you force host app to install it as well.