helperMissing and consistency for different expression types

[ErisDS]

When first developing Ghost, I ran into the helperMissing helper. For our purposes, throwing an exception was a bit much, so I added an override to make it log the error and continue.

However I've since noticed that helperMissing only gets called if you pass something to the helper:

{{test}} won't cause helperMissing to be called
{{test "testing"}} will cause helperMissing to be called
{{#test}}{{/test}} will cause blockHelperMissing to be called

This means that in some cases, using a helper that doesn't exist throws an exception, and in others, it fails silently. I realise that in the 'fails silently' case the helper could in fact be a key or path.

Having researched this a little bit, I found an issue which indicates that missing keys should cause helperMissing to be called: #318. More recently, someone raised this issue (#586) and the answer seems to me to have overlooked the fact that #318 states this should work.

Furthermore it indicates that the solution should be to override escapeExpression - however escapeExpression doesn't have any context such as the name of the helper/key which was attempted to be called, so it isn't possible to output a useful error at this point.

Context:
My ultimate goal here is to capture all of the problems (be they exceptions or silent failures) in a handlebars template, throw exceptions in debug mode, and log warnings otherwise. This is to make developing Ghost themes a little bit nicer.

I believe it ought to be possible (even if it isn't the default) to capture all issues in a template in a consistent way, and deal with them as we please. Given that there is already helperMissing and blockHelperMissing perhaps there could be a keyMissing method that gets called if the key does not exist. This method could just be a pass-through by default, but at least then users of handlebars.js could choose to override that functionality if needed.

[doowb]

I also like the idea of a keyMissing helper since it might help with figuring out when you're trying to access keys at a different level of the context than you expected.

[georgefrick]

This is a good idea, as long as the default is a pass-thru. I know of multiple projects that rely on a missing key simply printing nothing. To your point, it would be great to override that functionality to differ based on debug/logging level.

Kevin would you take a pull request on this?

[ghempton]

+1

As a workaround, we use a variant of what Ember.js core uses:

CustomHandlebars.Compiler.prototype.mustache = function(mustache) {
  if (!(mustache.params.length || mustache.hash)) {
    var helperName;
    var id = new Handlebars.AST.IdNode([{ part: '_triageMustache' }]);

    // Update the mustache node to include a hash value indicating whether the original node
    // was escaped. This will allow us to properly escape values when the underlying value
    // changes and we need to re-render the value.
    if (!mustache.escaped) {
      mustache.hash = mustache.hash || new Handlebars.AST.HashNode([]);
      mustache.hash.pairs.push(["unescaped", new Handlebars.AST.StringNode("true")]);
    }
    mustache = new Handlebars.AST.MustacheNode([id].concat([mustache.id]), mustache.hash, !mustache.escaped);
  }

  return Handlebars.Compiler.prototype.mustache.call(this, mustache);
};


CustomHandlebars.registerHelper('_triageMustache', function(path, options) {

  // Do something custom with `path`

});

When you compile you must pass stringParams: true as an option to get the name of the path.

See https://github.com/emberjs/ember.js/blob/master/packages_es6/ember-handlebars-compiler/lib/main.js#L246

[pschuegr]

+1 to this.

[kpdecker]

This seems to be at least tangentially related to #651. Will try to take both into account with any fix.

[kpdecker]

helperMissing should be more consistent now. Closing this issue for that specific portion. Moving tracking for the larger portion of generically being able to detect missing values (need more than just the helper, i.e. args, hash values, etc) to #651.

[kpdecker]

Released in v2.0.0-beta.1