Create an encapsulated "Dust template" class

[sethkinast]

Dust templates currently compile to a set of functions that are invoked via body_0 being registered by dust.register.

In #513 we suggest that these body functions could be members of a "Body" class so that we don't have to set magic flags on them to distinguish them from regular functions. In addition, .render() methods could be part of the class instead of invoking the function directly, etc.

[rragan]

It sure would be nice to make a way to compile a template to a CommonJS format so just require(xxx.dust) would work

[sethkinast]

I agree-- what form would the required object take? Would it have a .render() method on it, or do you require templates and then pass them to Dust?

[pixshatterer]

why not follow the proposal already in #330? seems like the pull request was blocked due to conflicts, but it looks like a good implementation

[semanio]

Agreed with @pixshatterer that #330 seems to be doing the same thing.

[sethkinast]

This is actually not about treating templates as modules. It's the need to not attach properties directly to the magic dust functions that themselves only function if dust is a global.

330 is not related but it's still no less nice to have. On Dec 5, 2014 6:15 PM, "Nate Hanna" [email protected] wrote:

Agreed with @pixshatterer https://github.com/pixshatterer that #330 https://github.com/linkedin/dustjs/pull/330 seems to be doing the same thing.

— Reply to this email directly or view it on GitHub https://github.com/linkedin/dustjs/issues/516#issuecomment-65881513.

[jjclark1982]

#330 is related because when you require() a dust file, you want the result to be an instance of a standard Dust template class, with standard methods such as .render().

In order to make a require handler that did not depend on subsequently calling the dust global, I had to attach ad-hoc render and stream methods alongside the existing magic properties. It would be better to use a standard class with standard methods.