Load paths for partials

[pushred]

After we get #103 sorted out, the next step is the distribution of blocks. I’m hoping to use npm for this, which will allow blocks to define versions and asset dependencies. The details of how the files will be organized still needs to be worked out but for any CSS/JS assets the plan is to define node_modules as a load path for Sass. Browserify supports npm module names, etc. via require.resolve(). Despite the documentation, it appears that express3-handlebars can also search multiple paths for templates.

So we need a way to define additional load paths for partials and add them to the partialsDir array before setting the module’s configuration. It’s likely that these paths won’t be recursively searched for templates so we’d likely need to add each module directory where a block exists, and directories therein if the template isn’t in the root (it likely will be). The partials should be namespaced by their module name but I suspect they won’t be if the scope is being set to the module directory. So some further work may be required to perhaps do something like gather up all templates from identified directories and pass a temporary/hidden location to the array.

Ultimately referencing such templates should look like this:

{{> module_name/template_name }}

i.e.

{{> lightbox/instagram }}
{{> stream/twitter }}

We’ll also be able to pass arguments for some customization possibilities.

[pushred]

ericf/express-handlebars#70 cleared the way for this yeah? Let's do it!

[joanniclaborde]

Been playing with this today, there are multiples ways this can be done:

1. Automatically add node_modules to express-handlebars' partialsDir. This means express-handlebars scans all locally installed modules for hbs files, and makes them available as partials. Pros: easy, all modules are available with real relative paths like universe.js/views/events. Cons: slow, node_modules can be huge because of nested modules. Partials are not cached in dev, so express-handlebars re-scans the whole tree at every request. Also, global modules are not available, unless we also add the global node_modules path, but those are not meant for requirable modules, so it shouldn't be an issue in general.
2. Like 1, but try to optimize express-handlebars as much as possible, like skipping nested node_modules and hidden directories, or adding an option to cache the external partials in dev.
3. Add another config file to Solidus, specifying which modules (or paths) should be available for partials. Pros: faster, unless you add a module with countless dependencies. Cons: yet another config file, more complex to implement in Solidus, with the namespaces and all.

Thoughts? Solution 2 sounds like a good plan, dev-wise...

[joanniclaborde]

Turns out adding a dir-specific caching option to express-handlebars is pretty easy. The first page load after Solidus is started can be slow (5-6 seconds here), but the next page loads are as fast as usual. I think we have a winner, unless you had other ideas?

[pushred]

Sounds good to me, might want to run it by the author (you'll be submitting another PR?) in case we're overlooking some horrible detail. Syntax-wise it feels similar to requiring modules otherwise, which is nice.

[joanniclaborde]

Yes I'll submit another PR, or fork the repo if he doesn't accept it. But the guy seems pretty responsive lately, so it should be fine.

[pushred]

I bet.. Yahoo just killed the project he works on (YUI).

[joanniclaborde]

What kind of internet stalker are you...

[Fauntleroy]

He's not as bad as me :)

[pushred]

What is this stalker accusation meme! I am merely plugged in 🔌

[joanniclaborde]

See ericf/express-handlebars#81