Helpers Organized in Folders

[localjo]

I think it would be helpful to have Handlebars helpers organized in their own folder, /helpers rather than having to put them all in the same helpers.js file. That would allow things to remain modular and reusable, and prevent us from having a mess of assorted helpers crammed into one .js file.

I think this would be more consistent with the organization of the other parts of Solidus sites. I believe Ember.js projects organize helpers in a similar way as well.

While working on the JasonAldean.com migration (https://github.com/SparkartGroupInc/jasonaldean.com/issues/3), I realized it would be nice to have the different helpers split out into different files.

[pushred]

Why not simply export helper functions as modules and require them into helpers.js, effectively treating it as an index module? It's the exact problem that modules are designed to solve.

[localjo]

That's another possibility. It seems like a Solidus project would be a little more cleanly organized though with just one directory that contains helper files, and no intermediary helpers.js to tie them in. That may just be my personal preference, I'm not sure that it really makes sense architecture-wise.

@joanniclaborde Did you have any thoughts on this?

[pushred]

The problem with that approach is that some magic would be required to require them all, convention over configuration. index files are how this is done in node, though that does still involve a little work in hooking up the exports. That file is just another module like any other though, and it's totally possible to automate the process. You could also opt to generate a more verbose index module but still automate the process as part of a Gulp workflow (with total control over the export names, globs, etc).

I prefer this sort of flexibility over baking it in, which would limit decisions down the road and require weird wrapper files to import any third-party modules as helpers.

[joanniclaborde]

I originally suggested this approach to @josiahsprague because we talked about this for the preprocessors. But both solutions are fine to me, as long as we're consistent.

[localjo]

The more I think about it, I think the exporting helper functions as modules and requiring them where needed is the best route. Organization-wise, I still think there's an argument for having a /helpers folder where helper functions are kept by default, similar to how /preprocessors are organized, even though they are included as modules. Though I'm not sure if there's a good way to encourage that convention.

[pushred]

My problem with automatic script loading is naming really. I like the ability to name exported functions however I want depending on the context they're used. I definitely agree with moving this stuff out of the root, that's something I'm currently thinking over among some other organizational changes like that.