I just wrote this up as a reply to another posters question without fully reading what they asked. I posted this reply, actually read the original post, then withdrew my reply, it was not applicable.
Not wanting to waist that effort, I post again here in a new thread. This is a topic I spent time learning recently, and thought other new users may value it. I am not asking for help, I hope I am preemptively offering it. If anyone has suggestions for improvements to this process I would love to hear them.
This inspires another JavaScript question; How does one attach a function like this to the Meteor namespace? Is it possible to make this a Meteor.callWithPromise() call? Would this be a good thing or a bad thing?
TT
Sure, you can attach a callWithPromise method to the Meteor object. Whether it’s good or bad is a topic for debate. I personally try not to monkey patch others code, but some people don’t have an issue with it. In fact several packages on atmosphere such as grove:call-async already do this.
As far as how to do it you just assign the function to Meteor.callWithPromise.
I posted a couple of blogs on this subject here and here.
There was a brief moment in time when we nearly got an official, automatically promisified Meteor.call. Currently, you’d need to do something along the lines of @copleykj’s suggestion.
@robfallows hope you are doing well You were our mentor in the first batch of meteor university . Last year I read this article you wrote and it seemed it was a bit tedious to implement async await in meteor. I tried my hands on express-apollo and used ES7 there and it was easy peasy to implement async await.
async/await is no more difficult in Meteor than in any other modern JavaScript platform (maybe easier, because there’s much less faffing about with babel).
The articles were written to encourage developers to use modern syntax in Meteor, not to suggest that Meteor was in some special way trickier than expected .
Having said that, there’s always room for improvement, and Meteor could really do with Promisified versions of Meteor.call, Meteor.apply and HTTP, at least (although they’re not difficult to add as a package). Perhaps it could also benefit from observables for reactive data.
However, playing catch-up applies to any established platform, and Meteor’s no different from any other in that regard. In the JavaScript world, platforms become established (read “contain legacy features”) very quickly. I think MDG’s doing an amazing job keeping Meteor relevant.
Hi @robfallows, glad to see you still working these forums! I read somewhere that Meteor will be getting “full” async/await support in 1.6.2? How will that change things?
It already does have full async/await support on both the server and the client.
Perhaps you’re referring to the upcoming legacy browser targeting with a separated bundle so that we can get a slimmed down bundle for evegreen browsers, where async/await need not be implemented by unnecessary polyfills and transpilation.
Either case, it still does not mean any change for your code. Just makes your app run eariler and faster in modern browsers.
Yup, that’s just about it, nothing to worry, nothing we’re missing, your standard javascript already fully applies to meteor’s build system while the build output is bound to improve as some of these tickets get resolved.
@serkandurusoy, my mentor in meteor university. How are you doing ? and @aadams good to see you both here. ( I am the one who came after a while )
I was reading through The exact thread yesterday. So 1.6.2 is about legacy browser support and decreasing bundle size wherein we already have async-await working for some time now in meteor right ? Gotta open up a dummy meteor app and try
Oh hey I did not realize you were here, too. Nice surprize Yup you should definitely catch up with what’s up here with Meteor, worth every second of it