Featuring async wrapper for Meteor.call

core
1

I’ve seen many Meteor projects using this wrapper to make meteor.call async by promising their callback into a Promise.

  async callAsync(name, ...args) {
    return new Promise((resolve, reject) => {
      Meteor.call(name, ...args, (err, res) => {
        if (err) {
          reject(err);
        } else {
          resolve(res);
        }
      });
    });
  }

My Idea was to add this small change to make the developer experience a little bit better.
This feature has its pull request here: Feat(callAsync): async method option to Meteor.call by Grubba27 · Pull Request #12151 · meteor/meteor · GitHub
Any opinions?
Also, If anyone has ideas that could make the Meteor developer experience better, I’m all ears :slight_smile:

3 Likes
2

What will happen to the feature wherein the behavior of the methods differ in client and server?

client: use callback
server: return value

1 Like
3

I think this should have been in core awhile ago. It’s a nice little change!

Also, If anyone has ideas that could make the Meteor developer experience better, I’m all ears :slight_smile:

FWIW for anyone who wants a better dev experience I really recommend using the mdg:validated-method package for any Meteor Methods. It lets you validate method args with SimpleSchema on both client and server and it supports mixins including the callpromise mixin to support returning a promise.

It also allows you to call Methods as a regular function without relying on the string like

Meteor.call('some-method-name')

which I always thought was a nasty magic string. Instead you just do

myMethod.call()

or

await myMethod.callPromise()

4

Wouldn’t in the future Meteor.call on the server have to be async as well? In such case it could be async on both sides, right?

5

I’m not sure what should happen first. The removal of fibers or this one.

6

I think doing this one is a good first step so this api will already be capable of the future changes

1 Like
7

There is a callAsync package that I have been using for a while which does the same job

8

Nevertheless, I believe my question is still a valid concern. There must be a way to make the transition easy for those who use these existing behaviors.

(I just checked the entire discussion in github and good to know that the existing behavior will be preserved to make the transition easy for us. Thanks)