N.depth folder access for partials, views and templates

[jaysaurus]

Hey Connor,

It'd be cool if I could register a folder as, for example, "views/partials/" but then have subfolders within that partials folder so I can structure a project's partials by controller, namespace or whatever.

for example, say I have a "Sample" model, I might want a directory: "views/partials/Sample/mainSamplePartial.hbs" etc.

All it'd take is a bit of async recursion using fs to work out what directories are in a partial folder and then read down the tree. You could have "viewsDirectoryExclusions", "partialDirectoryExclusions" and "templateDirectoryExclusions" arrays to manage any folders the client doesn't want the algorithm to look in (for example, should they have a structure where their partials are subsumed under their "views" folder).

Happy to assist if what I did last time was satisfactory. I'll do a better job of matching your linter, I'm probably a bit too used to working with mine to remember that other people have different preferences XD

cheers

Jay

[ConnorWiseman]

This feature's been added to the repository but isn't yet published on the npm registry; I don't feel as though it's complete.

I haven't implemented any sort of exclusion, but my feelings there are that users should probably not mix the two different template types in the same directory. In the use case you describe, however, I don't foresee it causing significant harm, as all view templates are compiled and cached only on render, and if a partial is never directly rendered by the application in place of a view...

What's conventional there, by the way? I've seen views and partials managed both ways (subdirectory, different directories entirely) and sort of aimed this package at the way that kept them separate, but now I'm second-guessing my choice.

I'm not happy about the way I tried to chop the base directory path off the front of every template's file path so that template names could have a sort of "namespaced," hierarchical structure based on their file path (see test/files/views/partial.hbs). It feels hacky and I'm not sure if it will work cross-platform, though Travis CI's Linux distribution handled it just fine. Do you suppose there's a better way of managing that than what I came up with?

I also wouldn't mind trying to adapt this to manage helpers, too, but that'll probably have to come at a later date. Also also wanted are tests for coverage of the new fs error cases in getPaths() but I'll manage that some other time.

What are your thoughts on this? Does it suit present needs without breaking anything? The tests I already have in place say 'no', but automation doesn't always give you terrific feedback.

[jaysaurus]

Wow, thanks for all this and apologies for the slow response! I've been up to my eyeballs of late during my spare time decoupling some stuff into npm modules! My use case for your module is an MVC that I'm working on that's heavily inspired by Groovy on Grails. Right now it wouldn't break my build (it's a WiP anyway so no worries on that front!)

I think you're a bit ahead of the curve allowing for namespacing hbs stuff and that gives you a bit of license as to how you'd like to structure it; I sense that quite a lot of implementations add views as an afterthought. If you weren't to namespace by directory, the alternative would probably be dot notation ala Java.

As for having 'views/partials'... I think I see what you mean. if, for example, you have "partials" as a directory in "views", the word "partials" now becomes reserved (which is kind of dirty). Maybe insist by convention that clients keep their folders flat:

/views
/partials

but allow the user to specify in config what their parent directory is, e.g:

HBS/views
   /partials

and in config:

{
...
hbsRoot: `${ProjectRoot}/HBS/
}

Thereby reducing configuration and moving to convention. Your call :) one way or another, thank you once again for your hard work!