Tracker and async mongo methods

blaze
1

I tried to migrate some Blaze templates to the new asynchronous handling of mongo methods. At first glance, it is not possible to do this because the tracker is still synchronous. Here is a simple example:

Synchronous version

Tracker.autorun(() => {
  console.log('asynhHelper async start', Tracker.currentComputation); // instance of Tracker.Computation
  coll2.findOne({});
  console.log('asynhHelper async middle', Tracker.currentComputation); // instance of Tracker.Computation
  coll.findOne({});
  console.log('asynhHelper async end', Tracker.currentComputation); // instance of Tracker.Computation
});

Asynchronous version

  this.autorun(async () => {
    console.log('asynhHelper async start', Tracker.currentComputation); // instance of Tracker.Computation
    await coll2.findOneAsync({});
    console.log('asynhHelper async middle', Tracker.currentComputation); // null
    await coll.findOneAsync({});
    console.log('asynhHelper async end', Tracker.currentComputation); // null
  })

The synchronous version succeeds in intercepting variations in both collections, the asynchronous version clearly does not.

This worries me greatly since all our management is related to changes in the data of the collections. In real world mode, it is normal to have the need to cross-reference data from several collections to represent an aggregated element. I have noticed that the Tracker package, a basic component of the Blaze package, is the domain of Meteor. Is there a migration plan that supports both packages accordingly?

1 Like
2

Hello there!! Yeah, that is an issue :frowning:
but the at least was documented here
I was wondering if the following workaround code would make it work

  this.autorun(() => {
    console.log('asynhHelper async start', Tracker.currentComputation); // instance of ??
    coll2.findOneAsync({}).then(sideEffectFn);
    console.log('asynhHelper async middle', Tracker.currentComputation); // ??
    coll.findOneAsync({}).then(sideEffectFn);
    console.log('asynhHelper async end', Tracker.currentComputation); // ??
  })

I know it is not ideal but for the time being is what I could try.

Is there a migration plan that supports both packages accordingly?

Do you mean tracker supporting async code?

3

Thank you @grubba

the workaround does not work because currentComputation is lost at the first async and the subsequent calls are not connected to the contest. Consider that this is just an example, it could also be several asynchronous calls.

Yes, I meant if there are plans for Tracker and Blaze asynchronous support. I am trying to integrate Zone.js and make the calls asynchronous. For us it is crucial because there are 7 years of developments in Blaze that I would like to protect. I would like to know what your plan is in this regard

4

Hi @pbeato, @grubba,
Super interesting question.

On the client it does not make sense to use async calls. Remember on the client the mongo calls are simply a synchronous reactive lookup in minimongo. I suspect any client implementation is an immediate resolve of the Promise. Might make sense for Meteor to not even support client side async calls to avoid confusion?

So for autorun functions you should be able to continue to use the non asynchronous calls.

5

We’re actively working on the possibilities here and will soon post about the possibilities and their drawbacks. (We’re focusing on React now, but it affects all of the UI integrations.)

2 Likes