Subexpressions don't work as expected

[halfdan]

This is a follow up on #55 but might not directly be related.

Using sub-expressions like {{encode (url)}} (as in https://github.com/halfdan/hbs-weird/) where the url helper returns a URL and encode executes encodeURIComponent the expression is replaced by only the result of the url helper. Using {{encode "http://foo.bar/?baz=muh"}} on its own seems to work just fine.

Example case in https://github.com/halfdan/hbs-weird/

[mgutz]

Thanks. I'll look tonight or tomorrow.

[mgutz]

I cannot think of a quick solution right now. Looked at it for a couple of hours and I'm drawing a blank.

Here is what is happening

1. Express-hbs wraps weird into a promise and returns to handlebars a unique token to be replaced later.
2. (weird) returns a token say zXyt234
3. Handlebars executes encode(zXyt234) returning zXyt234. Subexpressions cannot be deferred values.
4. AFTER handlebars has invoked all functions and subsequently all promises resolved, express-hbs replaces __zXyt234 with the result of weird which is the original url.

[ErisDS]

Out of interest does this work if both helpers are async? Or does that cause even more mess?

[halfdan]

When I change encode into an async helper I end up with tokens again:

Unexpected behaviour: __aSyNcId_lhqgvIz___

That's from encode (url) where both, encode and url are async helpers.

[halfdan]

@mgutz Any update on this?

[mgutz]

In the process of moving. Will look at this maybe next week.

[ErisDS]

I would like to know if it's even going to be possible to fix this. If not we need to reduce our reliance on async helpers. They're a very useful feature, but if they don't work well together with standard helpers when using subexpressions, then we have a bit of a problem with our API which we will need to resolve some other way.

[mgutz]

This is not an easy thing to do; short of forking handlebars to properly handle async helpers, any other solution would be kludgy at best. I'm leaning towards "wont fix".

[ErisDS]

I found this: handlebars-lang/handlebars.js#141

I think if you have an idea of how to implement this inside handlebars that it would gain traction. Ghost is one very clear example of why async helpers aren't just useful but pretty much required.

Do you have any thoughts on how to do it? I'd love to hear your thoughts on how it could be done in handlebars and how it might done in a 'kludgy' way here in express-hbs so that we can see how the best way to move forward is, and whose arm Ghost needs to bend to make it happen 👍

[nknapp]

@mgutz, could you have a look at promised-handlebars) I have written it in the past week and I have working test-cases for nesting async helpers within async block-helpers. Though, it has not been tested on larger examples yet.
Any feedback is appreciated.

[mgutz]

Will do. I might not be able to look at it for at least several days though.

[nknapp]

I think, promised-handlebars now has all the features I would expect from it.
The following cases all work with sync- and async-helpers in all combinations,
where "async" means that the helper returns a promise for the value rather than the value itself.

• Simple helper calls {{{helper arg}}}
• HTML-Escaping the result {{helper arg}}
• Nesting helpers in parameters {{helper (nested-helper)}}
• Helpers called from within block helpers: {{#block-helper}}{{inner-helper}}{{/block-helper}}
• Usage with built-in helpers {{#if (nested helper)}}abc{{/if}}
• Helpers as hash arguments {{helper param=(nested-helper) }}
• Helpers as arguments of a partial {{>partial (helper arg)}}

[nknapp]

@mgutz have you had any chance to look at promised-handlebars yet?

[bradvogel]

Bump

[jtwebman]

This is fixed now with my latest merge.