@Sayan751

From this perspective, I like @zewa666’s proposal to use the name promise instead. That way we can possibly use promise.any, promise.all, promise.allSettled, and promise.race. The naming feels more natural to me.

Although to support that syntax might be a major work. At first we might need something generic like the {TC}.PART attribute pattern also for template controllers, so that specific parts can be interpreted with specific meaning. If I am not mistaken, that’s a major infra to build.

That infra is already there. Whether to do it via @attributePattern or via @bindingCommand though depends on how you want to implement it.

The most obvious way that comes to mind is having 4 different template controllers for these 4 scenarios (probably one of those few cases where inheritance makes sense). Then you could “redirect” with attribute patterns:

@attributePattern('promise.PART')
class PromiseAttributePattern {
  'promise.PART'(name, value, parts) {
    switch (parts[1]) {
      case 'any': return new AttrSyntax(name, value, 'promise-any', 'bind');
      case 'all': return new AttrSyntax(name, value, 'promise-all', 'bind');
      case 'allsettled': return new AttrSyntax(name, value, 'promise-allsettled', 'bind');
      case 'race': return new AttrSyntax(name, value, 'promise-race', 'bind'); 
      default: // throw
    }
  }
}

class PromiseTemplateController { /* magic */ }
@templateController('promise-any')
class PromiseAnyTemplateController extends PromiseTemplateController { /* magic */ }
@templateController('promise-all')
class PromiseAllsettledTemplateController extends PromiseTemplateController { /* magic */ }
@templateController('promise-allsettled')
class PromiseAllTemplateController extends PromiseTemplateController { /* magic */ }
@templateController('promise-race')
class PromiseRaceTemplateController extends PromiseTemplateController { /* magic */ }

export const PromiseTemplateControllerRegistration: IRegistry = {
  PromiseAttributePattern,
  PromiseAnyTemplateController,
  PromiseAllsettledTemplateController,
  PromiseAllTemplateController,
  PromiseRaceTemplateController,
};

Inheritance could be avoided by using binding commands. Then you’d have to create an accompanying instruction and renderer that transforms the any, all etc into a hydration operation that creates a binding and a meta property on the template controller to indicate which kind it is. A little more involved, maybe an optimization worth looking into at a later time.

But attribute patterns should be an easy way to get the ball rolling?

Side note: this implementation means users could also do promise-all.bind instead of promise.all. That’s not a problem though imo. And if you wanted to support multi-attr bindings in the future, that could be accomplished as well if it was really needed:

@attributePattern('promise.PART')
class PromiseAttributePattern {
  'promise.PART'(name, value, parts) {
    switch (parts[1]) {
      case 'any': return new AttrSyntax(name, value, 'promise-any', hasInlineBindings(value) ? '' : 'bind');
      // etc
    }
  }
}

Another example that we can do is a containerless/templateless custom element for fetching data

<fetch url="/my/graphql" type="graphql" result.bind="fetchUserPromise">
    {
        user {
            name
            friends(id: ${query.friendId}) {
                name
            }
        }
    }
</fetch>
<template promise.bind="fetchUserPromise">
  <div then.bind="user">
    <b if.bind="user">${user.name}....</b>
    <span else>Not exist</span>
  </div>
  <div catch.bind="ex">Error fetching user data. ${ex.message}</div>
</template>

Apologies if I am missing the use case. But before bikeshedding the keywords, do we really need this much declarative power in html? To me, it seems simpler, more readable, and more powerful (since you can differentiate show vs if) to keep the promise resolving and catching in JS and simply put a show.bind or if.bind in the html.

resolving promises is a capability we absolutely need. although you can do everything from the VM, allowing binding directly to a promise can help to reduce boilerplate code (as already mentioned by other). but it’s absolutely needed in cases where you pass a value through a value-converter that return a promise. I find myself copying to every project I create a special binding-behaviour that handle promises just for this specific task.

but: on the other hand, I think we should not take it too far. for example: the next scenario is too far - in my opinion.

<template async.bind="promise1">
  <template fulfilled.from-view="data" async.bind="data.json()">
    <template fulfilled.from-view="json"> ${json.foo} </template>
  </template> 
</template>

It’s obvious that such channing should happened in the VM, and the view can be bounded to the resulting Promise. you don’t lose any capabilities - with a cleaner way of working.

I would also argue that allowing all, any, race. etc. are also an abuse and should not be implemented at all. all of those are functions that produce a single promise at the end. so it’s enough to allow a binding to that Promise and by that - allowing all of the scenarios mentioned and more.

so for instance:

instead of

<template async="value.bind: [promise1, promise2]; resolve: all">

we can do:

<template async.bind="Promise.all([promise1, promise2])">

or better yet as a developer, move the Promise.all([promise1, promise2])" part to the VM - save this expression as a variable, and bind the async to that.

to summarize: we need to find the fine path between nothing at all (what we have right now in V1), and absolute crazy stuff…

I really liked this: by @bigopon

<div await.bind="promise"></div>
<div then.bind="value">${value}</div>
<div catch.bind="ex">${ex.message}</div>

this is clean, understandable… and have all the power we need.

I think our aim shouldn’t be “mimic the way promise works” in html. With that in mind, we should simply the async/unsettled/fulfilled combo to just 2, with more natural name: await/then. The following example illustrates my comment:

<div await.bind="promise"></div>
<div then.bind="value">${value}</div>
<div catch.bind="ex">${ex.message}</div>

<div await.any="promises"></div>
<div then.bind="value">${value}</div>
<div catch.bind="ex">${ex.message}</div>

<div await.all="promises"></div>
<div then.bind="values" repeat.for="value of values"></div>
<div catch.bind="ex">${ex.message}</div>

<div await.race="promises"></div>
<div then.bind="values" repeat.for="value of values"></div>
<div catch.bind="ex">${ex.message}</div>

Doing it with await keyword, we avoid occupying the word async, and can save it for later use with observables. At least we don’t give the wrong impression that any kind of async will work. It’s only promise that is intended for this feature.

In order to have await.any/await.race/await.all, we need to enhance the template compiler, so that custom attribute can participate in the compilation process as well. In case some commands have special meanings when used with it. In this case .any/.all/.race is clearer.

I like the clear unsettled.from-view="...", in our implementation, we can make this default binding mode and simply using .bind will suffice.

Yeah it could be done but I don’t know what problem that would solve that would make it worth the perf impact of the extra parsing/binding overhead. These things can easily be accomplished programmatically as well. I’ve never seen a situation where I needed to dynamically change the event handled, only ignore it under certain circumstances (that’s what the event handler method is for…)

If it’s an avenue that must be explored, though, let’s do that in a separate RFC to stay on-topic 😃

Another example that we can do is a containerless/templateless custom element for fetching data

<fetch url="/my/graphql" type="graphql" value.bind="fetchUser">
    {
        user {
            name
            friends(id: ${query.friendId}) {
                name
            }
        }
    }
</fetch>
<template promise.bind="fetchUser">
  <div then.bind="user">
    <b if.bind="user">${user.name}....</b>
    <span else>Not exist</span>
  </div>
  <div catch.bind="ex">Error fetching user data. ${ex.message}</div>
</template>

noooooo lol, this is even more crazy than previous suggestions.

Besides what @Sayan751 's noted, we should also be aware all these resources are optional, which mean if you don’t use it, it won’t be in your final bundle, if that is also one of the concerns. All our our resources in v2 can be simply dropped if not needed, and it’s simpler to do so.

@akircher You are right that we can keep the resolving and catching of the promise in view-model and use a if/show in view to display the results accordingly. This is a perfectly valid solution.

However, if you have such instances in abundance, then it considerably increases the amount of boilerplate code. A natural progression thereafter can be a custom element that monitors the bindable promise, and has 2 slots for fulfilled and rejected content. And you can use that custom element to get rid of the boilerplate code. Again a valid solution.

One inherent limitation of the custom element approach is how it is styled, and whether or not it can be used seamlessly (style-wise) everywhere. On the other hand, having template controllers gives you freedom of using this construct anywhere possible, and those elements can be styled anyway wanted.

Even with these new template controllers, you might still want to encapsulate the code in a custom element (as said before) and use that. However, wherever you can’t use that custom element due to styles/layout issues, the new template controllers can be directly. IMO this brings more flexibility to play.

Apologies if I am missing the use case. But before bikeshedding the keywords, do we really need this much declarative power in html? To me, it seems simpler, more readable, and more powerful (since you can differentiate show vs if) to keep the promise resolving and catching in JS and simply put a show.bind or if.bind in the html.

I like the idea of renaming mode to resolve. Seems more natural to me.

One down side of using ( is that following with space will break, and user might be confused why it didn’t work.

<div catch( ex )>${ex.message}</span>

There are different individual preferences and we won’t be able to satisfy all. Fortunately, it is trivial to re-configure the binding syntax. We can provide an OOTB example or two on the most popular alternatives to the one we went with, so folks with strong alternative preferences can still have it their way. No problem with that.

It’s tricky to find a truly consistent syntax since the other control flow TC’s are all statements:

if (condition) {
  oneThing;
} else {
  anotherThing;
}

<div if.bind="condition">oneThing</div>
<div else>anotherThing</div>

And

switch (state) {
  case 1: thing1;
  case 2: thing2;
  default: somethingElse;
}

<div switch.bind="state">
  <div case="1">thing1</div>
  <div case="2">thing2</div>
  <div default-case>somethingElse</div>
</div>

So what syntactic concept are we trying to mimic for promises?

// option 1: old fashioned chaining
somethingWhileWaiting;
Promise.resolve(promise)
.then(value => {
  somethingOnResolve;
})
.catch(reason=> {
  somethingOnReject;
});

<div promise.resolve="promise">somethingWhileWaiting</div>
<div then.bind="value">somethingOnResolve</div>
<div catch.bind="reason">somethingOnReject</div>

// option 2: async/await
(async () => {
  somethingWhileWaiting;
  try {
    await promise;
    somethingOnResolve;
  } catch (err) {
    somethingOnReject;
  }
})();

<div async.bind="promise">somethingWhileWaiting</div>
<div await.bind="value">somethingOnResolve</div>
<div catch.bind="reason">somethingOnReject</div>

In neither case I see a 100% convincing parallel in anything that’s not super verbose (certainly not looking forward to nesting a try/catch in an async in a template), but option 1 does feel a lot more like it resembles the actual code. Maybe someone else has a way to present async/await in a more natural manner but so far I don’t think that will be the right terminology to use here.

The examples provided by @Sayan751 with async and pending/fulfilled/rejected don’t directly mimic a syntactic structure that is seen in real code unless you imagine the promise’s internal slots being accessible. Though with promise.resolve it is a bit easier to display it in psuedo code I think:

// hypothetical code if internal slots were accessible
const promise = Promise.resolve(input);
while (promise['[[PromiseState]]'] === 'pending') {
  somethingWhileWaiting;
}
while (promise['[[PromiseState]]'] === 'fulfilled') {
  somethingOnResolve;
}
while (promise['[[PromiseState]]'] === 'rejected') {
  somethingOnReject;
}

<div promise.resolve="input">
  <div pending>somethingWhileWaiting</span>
  <div fulfilled.bind="value">somethingOnResolve</span>
  <div rejected.bind="reason">somethingOnReject</span>
</div>

When taking that liberty of imagining the internal slots being accessible, I do think @Sayan751’s variant is the best in terms of consistency.

@Sayan751 You could also have a single template controller registered with 4 aliases, and then inject the instruction (just like compose does) to look at the original name that was declared, and use the res name from the instruction to determine the behavior. So the aliases would be promise.all, etc. You’d still need the attribute pattern to effectively turn promise.all into promise.all.bind then.

Cool. Just to further clarify then: attribute patterns are a template compiler extensibility point and they’re used in the broadest sense for determining resources and their bindings. This is also the api one would use to emulate the Vue or Angular syntax.

It might help to think of the parallel with configured routes. You register a route pattern to map from a url segment to a component / redirect / param, in much the same way you register an attribute pattern to map from an attribute to a either a binding, a custom attribute + binding, or simply a custom attribute. If you would not register the DotSeperatedAttributeSyntax then if.bind would cause the compiler to look for something declared as either @templateController('if.bind') or @customAttribute('if.bind'), neither of which would exist, so it then assumes if.bind is just an ordinary native attribute and do nothing with it 😃.

The only thing to be careful with is clashing. Come to think of it, it’s probably not good to throw in the default case, because that would make it impossible for anyone to declare a binding with the name promise. This is probably a better and more compatible idea:

@attributePattern('promise.PART')
class PromiseAttributePattern {
  'promise.PART'(name, value, parts) {
    switch (parts[1]) {
      case 'any': return new AttrSyntax(name, value, 'promise-any', 'bind');
      case 'all': return new AttrSyntax(name, value, 'promise-all', 'bind');
      case 'allsettled': return new AttrSyntax(name, value, 'promise-allsettled', 'bind');
      case 'race': return new AttrSyntax(name, value, 'promise-race', 'bind'); 
      // this is identical to the behavior of DotSeperatedAttributeSyntax
      default: return new AttrSyntax(name, value, parts[0], parts[1]);
    }
  }
}

Just had some more thoughts on this. For await.bind, it’s a bit off to use await to express an async piece of UI for the reason in your comments, and pending state.

Which means the following:

<div await.bind="fetchInfo(userName)">Loading...</div>
<div then.bind="user">Loaded. User name is: ${user.name}</div>

is probably not the best.

But if we are to map our naming 100% to Promises, and the real meaning of its internal states, we will have to do:

<template async.bind="fetchInfo(userName)">
  <div pending>Loading...</div>
  <div fullfilled.bind="user">Loaded. User name is: ${user.name}</div>
</template>

It feels a bit unnecessarily detailed.

Though with my proposal, we cannot express the following as there’s no nesting:

dont show any loading state
<template async.bind="fetchInfo(userName)">
  <div fullfilled.bind="user">Loaded. User name is: ${user.name}</div>
</template>

So maybe we cannot use await.bind. I don’t have a better naming pairs now, so I think while there’s some issue with async in terms of naming, it’s probably not bad to go ahead with it. If we really want to have another name, I think resolve is a better name than promise.

For

<template async="value.bind: [promise1, promise2]; mode: all">

Maybe rename mode to resolve?

<template async="value.bind: [promise1, promise2]; resolve: all">
<template async="value.bind: [promise1, promise2]; resolve: any">
<template async="value.bind: [promise1, promise2]; resolve: race">
<template async="value.bind: [promise1, promise2]; resolve: allSettled">