Custom helpers / custom handlebars library

[iby]

Alan, thanks for putting this out. I remember seeing somewhere that custom helpers are not supported, but can't find that information now. Is this true?

Also, if I understand correctly, the loader pulls it's own copy of handlebars library and it kind of sucks that there's no way to use the dependency from the project. Is there any way to add that option into configuration? I'm not a guru on the subject, but something like configuring an alias in the main webpack.config and passing it to the loader to use instead of the default library would be fantastic.

[iby]

I actually see https://github.com/altano/handlebars-loader#details about the helpers there, but can't figure it out. Can you provide an example how to use it? I'm trying to get this functionality incorporated into the template:

Handlebars.registerHelper('json', function(context) {
    return JSON.stringify(context);
});

{{json user}}

[altano]

As you can tell from using this thing, it is basically almost completely untested. I used almost none of this functionality in my personal project. I just did very basic templating. I did some work to test these cases now, but not in proper unit tests. Let me know if you keep hitting issues and I'll keep trying to fix them.

Fixed in 51f32d5 / v0.1.2

You need a module for the helper, e.g.:

json.js

module.exports = function(context) {
  return JSON.stringify(context);
};

template.js

<div>
  {{> ./SameDir}}
  {{> ../../Component/FileForm}}
  {{json context}}
</div>

Due to how Handlebars parses the template, the helper has to be in the same directory as the template that references it. I know that sucks but I'm not sure how to workaround it. Let me know if it's a problem and I'll brainstorm some more.

[altano]

@sokra: regarding this comment I made:

Due to how Handlebars parses the template, the helper has to be in the same directory as the template that references it.

Is there any chance you can make loader.resolve respect the "resolve" configuration option that webpack is using so I could solve the above problem? i.e. if someone sets resolve.fallback in webpack, loader.resolve should respect that? That makes sense conceptually, right?

Thanks!

[sokra]

@altano It should be this way.

[iby]

@altano, thanks man. I think it makes perfect sense to use them from the same folder as the template, but as you're saying, is there another way to setup a loader-specific option in resolve config or pass some params to the loader to say where it should look if it's not finding it there?

Feels natural to have a separate folder for helpers and not use relative paths all over the templates. Maybe just pass query param? http://webpack.github.io/docs/using-loaders.html#query-parameters

{
    test: /\.hbs$/,
    loader: "handlebars-loader"
    query: { helpersDir: path(_dirname, '…') }
}

[sokra]

@altano ok, I read your commit and I think I need to clarify what resolve.fallback means.

resolve.fallback specifies a fallback directory for modules, which means this.resolve(.., "abc") can resolve to something in the fallback directory, but this.resolve(..., "./abc") will not resolve to something in the fallback directory, because it isn't a module.

I wouldn't redefine the meaning of resolve.fallback within the handlebars-loader. @ianbytchek option to specify an additional context for resolving helpers (partials) is much better. Allow an array too.

[iby]

@altano what do you think about this?

Also, if I understand correctly, the loader pulls it's own copy of handlebars library and it kind of sucks that there's no way to use the dependency from the project. Is there any way to add that option into configuration? I'm not a guru on the subject, but something like configuring an alias in the main webpack.config and passing it to the loader to use instead of the default library would be fantastic.

[sokra]

handlebars should be a peerDependency to fix this.

[altano]

v0.1.4 - 33f737e

• Switched handlebars from a dependency to a peer-dependency.
• Got rid of resolve.fallback code.
• Switched module '' prefix to '$' since '' is not a valid character
  in a handlebars identifier and it will not compile it correctly.
• Updated examples.

@ianbytchek, let me know if there is anything left you need.

[altano]

And thanks for the help, @sokra.

[iby]

@altano the only thing that I still need is to thank you 😉 appreciate your help man.

With regards to peer-dependency, it's definitely a x10 more flexible approach, but in real life when packaging for the web the project runtime dependencies would rather come from bower rather than npm. Is there a way we could pass an existing require name to depend on it, rather than using a build dependency?

[sokra]

We could offer a query param to the runtime path, or you could use the NormalModuleReplacementPlugin to replace the original runtime with one of your choice.

[altano]

Sorry @ianbytchek, I'm very busy for a while and can't take care of that. Please feel free to either submit a pull-request that makes the runtime a query param or use the module replacement plugin suggestion above.

[diurnalist]

Support for specifying a different runtime library path was added in #11

[sbnajardhane]

@altano commented on Mar 17 2014
Regarding this comment.
I have around 15 helper functions in my handlebar template, may be they will increase in future. So can I write all those functions in single handlebarHelper.js file and export from there.
I have tried to export helper function like modular jQuery pattern, but it didn't work.
handlebarHelper.js

module.exports = (function() {

    var helper1 = function(data) {
        return "helper1"
    };

    var helper2 = function(data) {
        return "helper2";
    };
    return {
        helper1: helper1,
        helper2: helper2
    };
})();

Any thoughts??
thanks