request: {{i18n "path/to/file"}} about handlebars-helpers HOT 6 CLOSED

I was thinking about something like that and was struggling with the concept a bit. The current approach requires on file per language so I assume that "path/fo/file" is rather "folder/to/file" right? I have a separate branch were I was experimenting with scoped i18n which basically is the same thing as you are mentioning.

If there is a way to load a file from a folder from the helper it probably be more effective than my approach.

from handlebars-helpers.

Is there another helper I can base myself off that does this kind of stuff? I want to try and adopt conventions whenever possible.

from handlebars-helpers.

Is there another helper I can base myself off that does this kind of stuff?

@doowb and I will work on putting something, would you mind creating an issue to request it so we can track progress against it?

If there is a way to load a file from a folder from the helper it probably be more effective than my approach.

Yes, there is. Really, a single helper could do just about anything that the average grunt task can do. So if you really wanted to go crazy you could replicate an entire build process from a single helper... not that you should, but just to make the point. So, for example, if you needed to you could copy files from folder A to folder B:

Handlebars.registerHelper("copy", function(a, b) {
  return grunt.file.copy(a, b);
});

Another example of what helpers can do is {{globWithContext}}, which shows how you can use minimatch patterns in a helper and pass in context: https://github.com/assemble/handlebars-helpers/blob/master/lib/helpers/helpers-files.js#L34-L49.

Again, these are just examples to illustrate that helpers can be very powerful.

from handlebars-helpers.

Can assemble be run without grunt though? Shouldn't I aim to make autonomous?

from handlebars-helpers.

Can assemble be run without grunt though?

Currently no, but we're planning a refactor of assemble and anything is possible for the future. we would love for you and your team to participate in this planning process here: https://github.com/assemble/refactor-planning. Sincit it's new, currently it's just some notes and placeholder files, but we want to start adding issues and having discussions regarding goals for the next major version of assemble.

Shouldn't I aim to make autonomous?

Well, that's your call, but IMO it's best to create the helper that you need for the job your doing. We're planning on labeling helpers somehow to make it easy to differentiate them based on the following:

• Is is specific to assemble?
• does it require grunt? (e.g. what are the dependencies of the helper)
• is it a block helper?

and so on...

Not all of this is documented (since it's new), but assemble now allows you to add helpers from node_modules by simply adding the name of the helper module to your devDependencies and then adding the same name to the helpers property in the assemble options. You can even use minimatch patterns for any helpers in node modules. I'll explain why this is important in a moment...

But since assemble makes it so easy to add helpers we've decided to do the following:

1. continue maintaining common utility helpers in the handlebars-helpers project. these helpers should be the most generic, baseline helpers with the fewest dependencies and the most stability.
2. split other helpers into individual modules here: https://github.com/organizations/helpers.

So, for example, continuing the point about adding helpers from node_modules and using minimatch patterns, let's say your project uses 25 different helpers that each exists in a separate npm module. if they all follow a common naming convention, such as helper-* you could either do this to add them to assemble:

options: {
  helpers: 'helper-*'
}

Or, IMO the better way to go would be to publish a npm package with a custom "collection" that really only consists of an index page that requires in the helpers you want to use. then just refer to that collection in assemble.

So I guess IMHO helpers are so easy to create, change and maintain that if you switch to another framework or stop using Grunt altogether we can either:

a. modify the helper or create another version that uses minimatch or other libs that don't require Grunt
b. you can still require grunt without using it for builds. this will make even more sense in the future after the grunt methods are split out into separate libs (see https://github.com/gruntjs/grunt-glob and https://github.com/gruntjs/grunt-file). they are planning on doing that soon.

And I'd be happy to help explore other options if it helps make things easier for you and your project.

from handlebars-helpers.

closing due to inactivity. please reopen if it still needs to be addressed

from handlebars-helpers.