Implement hooks for missing helpers

[sferencik]

Implement hooks for missing helpers. Handlebarsjs has these.

This would make it possible to address this need (from the 2.0 roadmap) (see also the Stack Overflow question).

[sferencik]

I'm considering making a PR. Before I do, I want to discuss the syntax.

The Handlebarsjs syntax is as follows:

Handlebars.registerHelper('helperMissing', function( /* dynamic arguments */) {
  var options = arguments[arguments.length-1];
  var args = Array.prototype.slice.call(arguments, 0,arguments.length-1)
  return new Handlebars.SafeString("Missing: "+options.name+"("+args+")")
})

I'm proposing different syntax, registerMissingHelper:

Handlebars.registerMissingHelper((writer, context, name, parameters) => {
    var paramList = string.Join(", ", parameters);
    writer.WriteSafeString($"Missing: {name}({paramList})");
});

I'm proposing this difference for several reason:

• The Handlebarsjs call isn't really registering a helper called "helperMissing". It's not something you would invoke using {{helperMissing foo bar}}. Instead, this gets invoked when you call {{myHelpre foo bar}} (i.e. make a typo in your helper name).
• Even in Handlebarsjs they have reconsidered, so the above now registers a hook rather than a helper. (See the release note and this code.) Following this change, it's now impossible to explicitly invoke the {{helperMissing}}.
• Note my proposed syntax has a name parameter in the handler. In {{myHelpre foo bar}}, the name would be equal to "myHelpre". Unlike in a normal helper, this is quite important to receive in the handler. The alternative is to pass the name in context.name, which is somewhat akin to Handlebarsjs ("helperMissing helper no longer has the indexed name argument. Helper name is now available via options.name.").

[sferencik]

In the spirit of my comment here, I'm now leaning towards making the hooks return the value rather than write it. This would modify the syntax like so:

Handlebars.registerMissingHelper((context, name, parameters) => {
    var paramList = string.Join(", ", parameters);
    return $"Missing: {name}({paramList})";
});

[oformaniuk]

Have a look at #336 (comment) for some insights regarding the hook you want.

I'm now leaning towards making the hooks return the value rather than write it

Right now it's not supported in current version. Your request can be achieved using version from my fork zjklee/Handlebars.CSharp (and I'm working on making PR back to the main repo).

[sferencik]

Somewhat related, I'm fixing an incompatibility with Handlebarsjs: a placeholder like {{foo}} should prefer a helper called "foo" to a variable called "foo". This already works if "foo" is a helper registered at compile-time, or a late-bound helper with arguments. I'm making it so that it also works if it's a late-bound helper without arguments.

I've verified the behaviour in Handlebarsjs.

Please see #353.

I've decided to separate the hook implementation into a different PR.

[sferencik]

@zjklee, thanks, that looks great, with the CI work and all.

I think #353 is orthogonal to your work (it's not the "hook" functionality) and should be done anyway since the behaviour now differs from the JS standard.

As for the hook, are you saying the "helper missing" functionality is now available in your implementation? Could you elaborate on this, please?

[oformaniuk]

@sferencik

I think #353 is orthogonal to your work (it's not the "hook" functionality) and should be done anyway since the behaviour now differs from the JS standard.

My fork has the same bug. Unfortunately due to a huge codebase difference I'm not able to apply your fix in-place. However I think I'd push the fix in next couple of hours.

As for the hook, are you saying the "helper missing" functionality is now available in your implementation? Could you elaborate on this, please?

It's not available by default. However can be simply added by implementing IHelperResolver:

public class MissingHelperResolver : IHelperResolver
{
    public bool TryResolveReturnHelper(string name, Type targetType, out HandlebarsReturnHelper helper)
    {
        Console.WriteLine($"MissingHelper: {name}");
        helper = (context, arguments) => $"MissingHelper: {name}";
        return true;
    }

    public bool TryResolveBlockHelper(string name, out HandlebarsBlockHelper helper)
    {
        Console.WriteLine($"MissingHelper: {name}");
        helper = (output, options, context, arguments) => 
            output.WriteSafeString($"MissingHelper: {name}");

        return true;
    }
}

[Fact]
public void MissingMethodResolver()
{
    var template = Handlebars.Compile("{{amoeba}}");
    
    Handlebars.Configuration.HelperResolvers.Add(new MissingHelperResolver());
    
    Assert.Equal($"MissingHelper: amoeba", template(null));
}

Note: to achieve MissingHelper behaviour resolver should be registered after template compilation as it also would be used during compile-time to resolve helpers. Easy way to achieve this would be by using IFeature:

public class MissingMethodResolverFeature : IFeature, IFeatureFactory
{
    private ICompiledHandlebarsConfiguration _configuration;
    
    public void OnCompiling(ICompiledHandlebarsConfiguration configuration) => _configuration = configuration;
    public void CompilationCompleted() => _configuration.HelperResolvers.Add(new MissingHelperResolver());
    public IFeature CreateFeature() => new MissingMethodResolverFeature();
}

[Fact]
public void MissingMethodFeature()
{
    Handlebars.Configuration.CompileTimeConfiguration
        .Features.Add(new MissingMethodResolverFeature());
    
    var template = Handlebars.Compile("{{amoeba}}");
    
    Assert.Equal($"MissingHelper: amoeba", template(null));
}

As far as MissingHelper is part of standard behaviour I should consider adding the feature by default. I consider the following syntax, similar to what I have for other features:

Handlebars.Configuration.ConfigureMissingHelperHook(
    returnHelper: name => (context, arguments) => $"MissingHelper: {name}",
    blockHelper: name => (output, options, context, arguments) => output.WriteSafeString($"MissingHelper: {name}"),
    log: name => Console.WriteLine($"MissingHelper: {name}")
);

I would also need to reconsider the order of invocations as with current implementation (assuming the fix similar to #353) IHandlerResolver code-branch (so MissingHelperResolver in it) would be invoked before trying to resolve variable.