Closed Aaike closed 8 years ago
I think a binding behavior would handle this. The scenario somewhat similar to the throttle and debounce binding behaviors we've already explored a bit
Syntax would be:
<div>
${ title.getValue("name") & then }
${ title.getValue("description") & then }
</div>
Couple things:
ah i see, thank you @jdanyow will track the other issue then ;)
you can keep this open- we have other issues tied to the main binding-behavior issue.
As anyone from Aurelia Devs reached to the Falcor dev team ? They are currently opening it to frameworks that want to support it and it shouldn't be too hard for you to get access.
Would be a pretty good story to have that supported out of the box.
You can contact Jafar Husain @jhusain to get access to the early preview.
i'm not sure about the then
... still on the fence about it.
like to point out though that async
makes sense with promises if you think about the async
/ await
keywords you get with es7.asyncFunctions.
Kinda agree with @Aaike on this one, then
looks kinda weird because you expect something coming after, async
translate better what is going on imho.
As for Falcor, I would definitely like to give it a try and test out the integration with Aurelia and how we can make the most of it.
@Aaike / @Tlvenn good point- async or await would be better.
I tried to contact @jhusain over a month ago, but he did not respond, so I'm not sure what else to do. I'll try again. I do think we could handle this as @jdanyow points out through our binding behaviors idea, after we add that. I might be interesting to find out if Falcor is using promises or if it's using observables, because we might need more than done binding behavior to handle these two scenarios.
Hey Rob,
Sorry about dropping the ball. We are using observables which have a then method which returns a promise. Support either, and you'll support falcor. JH
On May 28, 2015, at 9:41 AM, Rob Eisenberg notifications@github.com wrote:
I tried to contact @jhusain over a month ago, but he did not respond, so I'm not sure what else to do. I'll try again. I do think we could handle this as @jdanyow points out through our binding behaviors idea, after we add that. I might be interesting to find out if Falcor is using promises or if it's using observables, because we might need more than done binding behavior to handle these two scenarios.
— Reply to this email directly or view it on GitHub.
Hi @jhusain , thanks for dropping in. I believe that beside just supporting it, more can be done to optimize Falcor with Aurelia. Things like analyzing aurelia templates at compile time to feed a pre fetcher in Falcor, etc.. Would be great to have access to the early preview to explore this.
Let's figure that out. Can we arrange a hangout?
JH
On May 28, 2015, at 8:04 PM, Tlvenn notifications@github.com wrote:
Hi @jhusain , thanks for dropping in. I believe that beside just supporting it, more can be done to optimize Falcor with Aurelia. Things like analyzing aurelia templates at compile time to feed a pre fetcher in Falcor, etc.. Would be great to have access to the early preview to explore this.
— Reply to this email directly or view it on GitHub.
Hi Jafar, feel free to send an hangout invite to chris@magelo.com
@jhusain Let's set something up.
Great if you can step in Rob, you would be the one with the most insights on how to best leverage Falcor within Aurelia. Glad I could somewhat facilitate this.
Use case:
<template>
<div repeat.for="item in items">
${item}
</div>
</template>
@inject(HttpClient)
export class ViewModel {
constructor(httpClient) {
this.httpClient = httpClient;
}
items = httpClient.get('...').then((response) => response.content);
}
In this example, the repeat would be empty until the promise was fulfilled.
Workaround is to assign response.content to this.items
in the promise fulfillment. Not too terrible, but can get complicated when you are using promises everywhere.
@Zoltu This will be possible once we implement binding behaviors. That will happen after our binding optimizations. We are preparing for those now.
@jdanyow Async becoming in keyword in ES7, I would favor it over 'await'. it seems the template language try to leverage ES6 thinking/language as much as possible and using 'async' would follow on this path.
Personally I'd find await
more intuitive since that is the term you use with promises in the async/await proposal.
I believe await
is also becoming a keyword in ES7 and TS.
Yes async
/ await
are ES7 features but await
in the context of a template does feel a little bit weird while async
does translate the intention and what is going on behind the scene more clearly imho.
FYI @jdanyow has written an experimental plugin to the binding engine which adds support for promises and RX observables. You can find it here: https://github.com/jdanyow/aurelia-async
Thanks, @EisenbergEffect -- I left my feedback on the syntax discussion ticket: https://github.com/jdanyow/aurelia-async/issues/3
I think this is covered with the async plugin.
I would love to see support for asynchronous template binding. It basically needs the templating system to support promises.
Was checking out the video on Falcor and it looks very cool.
I am not sure how it would look like in Aurelia but they gave this example for Angular 2