Handle async code

[jankapunkt]

Blaze currently auto-calls functions:

Template.example.helpers({
  asyncTest () {
    return {
      foo: () => 'bar'
    }
  }
})

<template name="example">
  {{#with asyncTest}}{{this.foo}}{{/with}}
</template>

will lead to bar as output.

However, changing foo to an async function like so

Template.example.helpers({
  asyncTest () {
    return {
      foo: async () => 'bar'
    }
  }
})

we will get for the same Template a toString output of a pending Promise: [object Promise]

However, we should be able to handle Promises in 2022 in any context. This would imply a huge PR but I think this is a crucial candidate for Blaze 3 and the future of Blaze

[StorytellerCZ]

Agreed!
I'm thinking that both Meteor and Blaze v3 will be all about Fibers and Promises. I think things will move towards the same pattern of development and support as Node has.

[StorytellerCZ]

OK, I think this is something that we should include as a main feature in Blaze 2.7.
Sadly I'm currently unable to in any way participate in building this functionality.

[jankapunkt]

Maybe we can first collect what all needs to be supported, especially in combination with all new changes by Meteor 2.8+

Regarding asynchronous management, I think it is also useful to consider hooks: created, rendered and destroyed. Now callbacks are synchronous but we will often have asynchronous calls within them.

FYI: I tried implementing the Tracker context logic, currentComputation, with zone.js but it doesn't not intercept the native promises (async/await). Used with legacy version of the bundle it works but feels like going backwards. Does anyone know of alternative packages to do this?

[Grubba27]

My point of view regarding handling async code would be divided in two parts. Not sure if it makes 100% sense but it could be a way to implement this.
First we need to handle promises/promise-like functions. We could do something like svelte, as I commented in the other pr or other ways.

{#await promise}
	<p>...waiting</p>
{:then number}
	<p>The number is {number}</p>
{:catch error}
	<p style="color: red">{error.message}</p>
{/await}

in blaze could be like:

<template name="example">
 {{#with asyncTest}}
    {{#await this.foo}}
	<p>...waiting</p>
    {{:then bar}} 
	<p>result: {bar}</p>
    {{:catch error}}
	<p style="color: red">{error.message}</p>
    {{/await }}
 {{/with}}
</template>

Then or in parallel, we would need to handle how to make Meteor/tracker async / accept async dependencies. As for today it has its limitations regarding async

The idea is not bad, but Tracker has to support asynchronous processes and to do that I think it will have to track calls, a bit like Angular and Dart. Your Blaze example can already be done with reactive variables and a heavy memory overhead, but if we have no way to intercept changes to an asynchronous object we lose reactivity. Assume the following pseudo-example

const vars = new ReactiveVar();
Tracker.autorun(async () => {
  const user = await Meteor.userAsync(); 
  const a = await coll.find({userCode: user.profile.companyCode).fetchAsync();
  const b = await coll2.find({extCode: a.extCode).fetchAsync();
  vars.set(b):
}) 

Changes coming from the DDP are not intercepted because on the first await the autorun loses context. Losing the native Meteor reactivity has a big impact.

My opinion is to keep Minimongo client-side synchronous at least until the Tracker problem is solved.

[polygonwood]

The concept of synchronous Minimongo access is something I suggested also in the main Meteor Async PR discussion: async focus can go first to Meteor.call use cases. It would reduce impact to smaller set of Tracker async cases one has to deal with.
In my opinion, finding a solution for the predictability of the onCreated, onRendered, onDestroyed sequence, and the concept of helpers kicking in after onCreated only, is a more impacting challenge to address.
If one could be sure that a OnCreatedAsync hook would be waited for before the OnRendered or OnRenderedAsync hook is called, that could make it easy to refactor these hooks to using async back end calls.
The next thing could be await-ed event hooks, because these are also the trivial places to find async back end calls. Helpers are conceptually already more or less async since they fire once and by reactiveness.

[polygonwood]

Changes coming from the DDP are not intercepted because on the first await the autorun loses context. Losing the native Meteor reactivity has a big impact.

@klablink I observed this (indirectly) by turning a helper into an async helper, can you elaborate why the context is lost after the first await ?

My opinion is to keep Minimongo client-side synchronous at least until the Tracker problem is solved.

Agreed !

@klablink I observed this (indirectly) by turning a helper into an async helper, can you elaborate why the context is lost after the first await?

Hi @polygonwood

Blaze's reactivity is based on Meteor's Tracker package. This uses a global variable, currentComputation, to map the relationship between a function to be called when a certain reactive variable changes and/or a minimon search. Now, if the process becomes asynchronous, on the first await the currentComputation will lose the reference for the rest of the calls.

For better understanding I will insert the code extract of Current Tracker:

_compute() {
    this.invalidated = false;

    var previous = Tracker.currentComputation;
    setCurrentComputation(this);
    var previousInCompute = inCompute;
    inCompute = true;
    try {
      withNoYieldsAllowed(this._func)(this);
    } finally {
      setCurrentComputation(previous);
      inCompute = previousInCompute;
    }
  }

As you can see, this._func must be synchronous to work in the current context, otherwise setCurrentComputation(previous) is executed immediately, losing context.

There has been much discussion on the subject (see this PR), and it seems that in Meteor version 2.10 there will be the possibility of invoking asynchronous functions by passing the tracker context. This will mean a major change for Blaze and many client packages.

[polygonwood]

@klablink thanks for the clarification and the pointer to the PR

…

On Mon, Jan 9, 2023 at 8:59 AM klablink ***@***.***> wrote: @klablink <https://github.com/klablink> I observed this (indirectly) by turning a helper into an async helper, can you elaborate why the context is lost after the first await? Hi @polygonwood <https://github.com/polygonwood> Blaze's reactivity is based on Meteor's Tracker package. This uses a global variable, currentComputation, to map the relationship between a function to be called when a certain reactive variable changes and/or a minimon search. Now, if the process becomes asynchronous, on the first await the currentComputation will lose the reference for the rest of the calls. For better understanding I will insert the code extract of Current Tracker: _compute() { this.invalidated = false; var previous = Tracker.currentComputation; setCurrentComputation(this); var previousInCompute = inCompute; inCompute = true; try { withNoYieldsAllowed(this._func)(this); } finally { setCurrentComputation(previous); inCompute = previousInCompute; } } As you can see, this._func must be synchronous to work in the current context, otherwise setCurrentComputation(previous) is executed immediately, losing context. There has been much discussion on the subject (see this PR <meteor/meteor#12294>), and it seems that in Meteor version 2.10 there will be the possibility of invoking asynchronous functions by passing the tracker context. This will mean a major change for Blaze and many client packages. — Reply to this email directly, view it on GitHub <#364 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMTJC22FOWAUNR67PE4P56LWRPAOXANCNFSM5R2FQQQA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sebastianspiller]

Hello from Germany 😃

I saw Tracker.withComputation in 2.10 and had a look on blaze, how hard can it be to make it work? 😅

I could quickly asynchronize some functions and I could write some self resolving helpers in a demo project, I was enthusiastic about it and wanted more 😬, when I saw no stringified [object Promise], but when I started to dive deeper, everyhing became async, like Blaze.renderWithData, maybe I did s.th. wrong and one false placed async has a huge consequence on the whole code base.

At the moment, async pops up everywhere, what I don't want because then the whole API will be async, too, in future. I have problems now, that the Blaze.View is missing.

I will keep on and just wanted to mention, that someone's working on it and want to know, if someone else gives it a try at the moment. Simply putting async everywhere doesn't seem the solution and I may think of another approach.

Regards 💯

[Grubba27]

Probably, to make this happen, you will need to use .then other than async, IMO I would make this a two-step approach, one keyword like withSync to get the promise and then unwarp it, that is the second step, where it could resolve to a value that can be stringified and in sync. Or it can resolve to an error that can also be stringified.
It would look a lot like svelte but is the way with the best DX