Upgrade to Handlebars 3.0 #105
Conversation
This upgrades to Handlebars 3.0 and makes backwards-incompatible changes to the ExpressHandlebars API. Since Handlebars had a major version bump, it seemed appropriate for this package to have a major version bump as well, so I took the liberty of refactoring some things. - Add `compilerOptions` config property which is passed along to `Handlebars.compile()` and `precompile()`. - Expose ExpressHandlebars metadata to the `data` channel during render (#101). This metadata is accessibile via `@data.ExpressHandlebars.*` - New "protected" hooks for AOP-ing template compilation and rendering, all of which can optionally return a Promise: - `_compileTemplate()` - `_precompileTemplate()` - `_renderTemplate()` For most apps this will be a drop-in replacement to v1 of this package, and using Handlebars 3.0 should be a drop-in replacement as well. That said, here's the changes that potentially break back-compat: - Removed using `prototype` props for default config values. - Removed `handlebarsVersion` from instances and `getHandlebarsSemver` static function on the `ExpressHandlebars` constructor. - Replaced undocumented `compileTemplate()` hook with the protected but supported `_compileTemplate()` and `_precompileTemplate()` hooks.
|
One more request, It's not a huge deal, maybe you could just make that property name configurable? |
Yeah it is, I'll sleep on it.
I'd rather not add an option for this but instead keep it fixed, at least for now. So if the reason you want it configurable is to have a shorter name, I'd rather just change the name before I cut the release 😄 |
|
Thanks! Yeah, I just wanted the shorter name. Not to mention, having it capitalized like that just sticks out like a sore thumb in the apps I write. :P |
Conflicts: lib/express-handlebars.js
|
I will be merging this in the next couple of days, so if anyone has feedback let me know. |
|
any timeline when it'll be merged to master? :) |
|
@adon-at-work I hope to find time to finish this by updating the README docs and publishing to npm today. |
|
OK. Thanks. |
|
Released as |
This upgrades to Handlebars 3.0 and makes backwards-incompatible changes to the ExpressHandlebars API. Since Handlebars had a major version bump, it seemed appropriate for this package to have a major version bump as well, so I took the liberty of refactoring some things.
compilerOptionsconfig property which is passed along toHandlebars.compile()andprecompile().datachannel during render (Inject more data to handlebars during render #101). This metadata is accessibile via{{@exphbs.*}}_compileTemplate()_precompileTemplate()_renderTemplate()For most apps this will be a drop-in replacement to v1 of this package, and using Handlebars 3.0 should be a drop-in replacement as well. That said, here's the changes that potentially break back-compat:
prototypeprops for default config values.handlebarsVersionfrom instances andgetHandlebarsSemverstatic function on theExpressHandlebarsconstructor.compileTemplate()hook with the protected but supported_compileTemplate()and_precompileTemplate()hooks.