feature suggestion | Synchronous/Asynchronous Helpers

[robincsamuel]

Registering a helper as Sync or Async, It helps to listen for callbacks, and get the data from callback.

[kpdecker]

This has come up in the past but we didn't act on it as the use case wasn't clear. Since handlebars still has to wait until all of the data is available to render providing async evaluation is simply a convience for something that the code that generates the context can do in a much more efficient manner.

Basically adding async evaluation at this point would be quite expensive both in terms of compatibility and runtime performance that I don't quite see a use case for right now. Do you have a concrete example of what you are trying to do?

[robincsamuel]

I agree with the performance issues, but I think, it will be better, if we can optionally make it aysnc, for example, RegisterHelper & RegisterHelperAsync, or anything like that.

Actually, I came to think about these async handlebars, while i work with node.js. I am working on some applications using express.js & the template engine i use is handlebars. So, If i need to get some value from a database call, while compiling the view, its not possible with this synchronous working,

For example,

Handlebars.registerHelper('getDbValue', function(id) {
     var Model = require('./myModel.js');
     Model.getValue(id, function(data){
           return data;
     });
});

The above example will not work, and returns nothing. The following is my concept. And, I don't know, if it is totally right or it can be implemented or not. Just using a callback function instead of return, in case of async method.

Handlebars.registerHelperAsync('getDbValue', function(id, callback) {
     var Model = require('./myModel.js');
     Model.getValue(id, function(data){
           callback(data);
           //or
           //callback(new Handlebars.SafeString(data)); //in case of safestring.
     });
});

I am experiencing more issues like the above one, and I can show more example according to my scenario, if anyone is interested in this feature.

Thanks

[jwilm]

@robincsamuel, When including database lookups in view generation, the whole idea of MVC separation goes at the window. I think you are arguing that you might not know you need the data until the view is being rendered, but to me that suggests functionality that should be implemented at the controller level rather than when generating your view. Combined with the performance considerations @kpdecker mentioned, async helpers just seem wrong. -- my 2c

[robincsamuel]

I just used that example to convey my problem. And I am not trying to argue, but, just made a suggestion. I hope, it will help if we call a function with callback from the helper. Anyway, thanks for your time :) @kpdecker @jwilm

[kpdecker]

At this point the stance of the project is that data resolution should be done prior to calling the template. Outside of the business logic in or outside of the template concerns, async resolution is more of utility behavior that other libraries such as async are much better suited at handling.

[tomasdev]

I want to comment something. Even though it would be throwing out the window the DB example, this could be really helpful for mutational templates. For example, a template with "subviews" inside, and that you don't want to split into several other templates. I just want to update a part in the view, and have a simple logic for that, instead of either repainting my whole view (flickering effect) or having my controller to build the whole thing for all these "mini views"

What do you think?

[robincsamuel]

@tomasdev I mean that :)

[ErisDS]

This feature is made available in node with express if you use https://github.com/barc/express-hbs. However the async version of helpers do not play nicely with subexpressions and a few other edge cases.

I would like to see this feature reconsidered for inclusion in handlebars, or at least consider how handlebars core can better support this kind of extension.

I believe Ghost demonstrates a clear and valid (although perhaps uncommon) usecase for async helpers, because our view layer is customisable.

On the frontend, all of Ghost's templates are provided by the theme. The theme is a very thin layer of handlebars, CSS and client JS, the only data it has access to is that which we provide in advance. It does not have access to a controller or any behaviour changing logic. This is very deliberate.

In order to expand out the theme API, we want to start adding helpers which define additional data collections the theme would like to make use of. For example something like:

{{#fetch tags}}
.. do something with the list of tags..
{{else}}
No tags available
{{/fetch}}

Ghost has a JSON API which is available both internally and externally. So this fetch query would map to our browse tags function. It doesn't need to use ajax/http to all the endpoint, instead, an async helper can fetch this data from the API internally and carry on as usual.

I don't argue that this is a common use case, and I accept it breaks the standard MVC model, but I believe it is valid and useful.

[robincsamuel]

@ErisDS Great news! And me too don't argue that its common issue, but it helps.

[ErisDS]

It's worth noting in this case, that many of the operations we are currently using async helpers for are synchronous under the hood, but they're structured as promises.

To give a detailed example...

All data in Ghost is accessed via an internal API. This includes global info like settings. Requests to the settings API hit a pre-populated in-memory cache before hitting the database, so we're actually just returning a variable, but by structuring this as a promise it's easy to go off to the database if we need to.

It also ensures everything is consistent - otherwise the settings API would be synchronous, and all the other internal data requests would be async, which would make no sense.

I know that structuring everything with promises can be quite confusing at first, but it is one of those things that you don't understand how you lived without once you've got it. With generators coming in ES6, support for asynchronous resolution of functions will baked right in to JavaScript - and this similar issue: #141 mentions that it would be nice to make handlebars work with yield.

I'm not sure how the coming release of HTMLbars might impact on this, but I think it at least warrants further discussion.

[rikkertkoppes]

Ran into another use case while trying to create a helper for acl resolution. This would fit nicely into my templates:

        {{#allowedTo 'edit' '/config'}}
            <li>
                <a href="/config">Config</a>
            </li>
        {{/allowedTo}}

But the actual isAllowed method from node-acl is asynchronous (allowing a database backend for instance).

A workaround is to fetch all the user permissions beforehand (allowedPermissions), but that's kinda itchy

[ErisDS]

@kpdecker Any further thoughts on these use cases?

[kpdecker]

@ErisDS I understand the desire here but I severely doubt this will ever make it into the language in callback or promises form. This is something that is very hard to do cleanly from an API perspective and effectively requires us to rewrite large portions of the template engine to support it. My recommendation is that all of this be handled before the rendering cycle is entered by the upstream model/data source.

The yield idea is an interesting one but if someone wanted to take a look at what would be required there, that would be an amazing research project, but browser support for that seems very far off to me and I honestly haven't messed around with any of those features yet on any of my projects.