Handle Helpers at Ember.js

I'm trying to get a seemingly simple Handlebars helper so that I can mark an element as active in the {{each}} block if it matches the identifier of the selected one.

Here is one attempt using some kind of helper that I found on the Internet.

Handlebars.registerHelper('ifequal', function (val1, val2, fn, elseFn) { console.log(val1); console.log(val2); if (val1 === val2) { return fn(); } else if (elseFn) { return elseFn(); } }); 

My friend also has a violin for more of the "Handlebars-way" attempt .

So, before everyone tells me to wrap the element in the view and use didInsertElement or something like that, let me ask my real question: Do steering assistants in ember help in this case? My helper expects a value and gets a string. Is this expected behavior?

+4
source share
2 answers

This seems like normal behavior,

You can try something like:

 var getPath = Ember.Handlebars.getPath; Handlebars.registerHelper('ifequal', function (val1, val2, options) { var context = (options.fn.contexts && options.fn.contexts[0]) || this; var val1 = getPath(context, val1, options.fn); var val2 = getPath(context, val2, options.fn); console.log(val1); console.log(val2); if (val1 === val2) { return options.fn(this); } else{ return options.inverse(this); } }); 

Fiddle: http://jsfiddle.net/73wtf/28/

Ref1: https://github.com/emberjs/ember.js/blob/master/packages/ember-handlebars/lib/helpers/debug.js Ref2: http://handlebarsjs.com/block_helpers.html

+2
source

In registerHelper it passes the binding string instead of the actual value of your function. That way you can use getPath to get the actual value. In any case, I would agree that this behavior seems "unnatural." I assume the reason for using the binding string is to do an automatic update.

0
source

All Articles