-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Nested Helpers #222
Comments
Something like this, (or modifiers) would be nice. For now it's possible to do something like: {{capitalizePlural type count}} You can create your own helpers and call them with something like:
|
Of course, but that isn't particularly scalable. |
I think this is unlikely to be supported, but I'll leave this open for now. |
I plus one this |
Here is a hack that works to all cascading helper calls. Basically, testing to see if the first argument is a function and if so calling it with the rest of the arguments to generate the result that this help wants to work on. // Setup the helpers
Handlebars.registerHelper('sum', function(left, right) {
return left + right;
});
Handlebars.registerHelper('numFormat', function(num) {
// Hack around Handlebars by testing for function and using
// that to calculate the num.
if (typeof(num) == 'function') {
num = num.apply(null, Array.prototype.slice.call(arguments, 1));
}
// Do that actual work
return d3.round(num, 1);
});
// Use this template
var t = Handlebars.compile("{{ numFormat sum 1 2}} === {{ numFormat 3 }}");
assert('3 === 3', t()); |
+1 |
This is largely intentionally. For format tweaks, you can always define computed properties on your view to modify the format. One of the primary goals of Handlebars is to make the primitive syntax simple enough to make it possible for us to attach bindings without a lot of accidental mayhem. If you look in the issue tracker, you'll see that there are still some issues related to interactions between existing helper styles (like Perhaps some day, when the existing bindings are extremely solid and mature, we can look into adding new features. For now, if it is possible to implement something via computed properties (or other existing primitives), I'm going to lean heavily in favor of using those primitives over adding new syntax. |
It could be great to have, something like applying i18n to existing views, else we need to extend views and do a lot of work around. If someone has nailed this problem, kindly share with me. |
@Trigmatic: +1 |
@matt001 I had tried using the thing indirectly {{#T frontend.signin.password}} But looks so dirty, a nested helper for this very case made sense. |
@Trigmatic +1 the same problem happened to me #432 and the only solution I found was compiling those nested helpers at runtime, but it seems wrong because if you nest too deep it gets ugly. Most of the problems that led me to this was likely internationalization helpers and custom classes with "if" statements.. I saw that Ember.js solve this last problem with string statements which makes smells even more. |
by the way, just created a handlebars plugin for it as a workaround for now https://github.com/mateusmaso/handlebars.nested |
+1 |
1 similar comment
+1 |
I know this isn't exactly in line with the spec/best practices, but if anyone is trying to make the hack @my8bird posted work with the the newer versions of handlebars the following snippet will modify the compiler to generate compatible functions. Handlebars.JavaScriptCompiler.prototype.lookupOnContext = function(name) {
this.push(this.nameLookup('depth' + this.lastContext, name, 'context') + ' || helpers.' + name);
}; |
i18n begs for this addition |
+1 |
Great news for all that need this. From the docs: http://handlebarsjs.com/expressions.html
So you can now do something like:
Thanks for adding! |
There are a good number of situations (at least in my experience) where it would be handy to be able to nest helper calls, such as capitalizing and pluralizing a word. Unless I've missed it, Handlebars doesn't seem to support doing so.
I could see the syntax being something like:
or:
Which, with count = 5, type = 'person', and a smart enough pluralize helper, would yield:
The text was updated successfully, but these errors were encountered: