Continuing the discussion from HTMLBars in 1.10.0-beta.4 - template must be a function:
Ok, so to summarize from my previous post:
- “Legacy” ember app, no ember-cli, bower, require.js, common.js.
- Build process based on grunt-ember-templates
- Handlebars templates precompiled on the server and served with handlebars-runtime
- Manual update, without the easy ember-cli based option.
Here are the lessons.
-
You no longer need an EmberEnv switch to enable HTMLBars. There was a short lived bug that had produced some misleading google results.
-
grunt-ember-templates that is on npm ATM doesn’t support what is needed to make this work, but their master on git has the needed fixes. I believe this will be fixed shortly.
-
There is no replacement for handlebars and/or handlebars-runtime js files you needed to link in manually. Htmlbars is now baked into ember.
-
There’s an ember-template-compiler project on git. However the version there is 2 months old (last stable) and doesn’t support HTMLBars. That led me on the wrong path of believing I needed to utilize…
-
HTMLBars project on github. I actually hacked together a grunt task using this raw compiler and it actually worked… until I tried using the “
{#each}
” helper.I spent a good few hours digging through the output of both github-derived and baked-in htmlbars compiler. Here’s what it comes down to:
-
template:
{#each breadcrumb in breadcrumbs}
-
output from the github master compiler:
block(env, morph2, context, "each", [get(env, context, "breadcrumb"), get(env, context, "in"), get(env, context, "breadcrumbs")], {}, child0, null);
-
output from the baked-in compiler:
block(env, morph0, context, "each", [get(env, context, "breadcrumbs")], {"keyword": "breadcrumb"}, child0, null);
So, either “native” handlebars doesn’t support #each helper, or one of the versions is out of date. Either way, that led me back to…
-
-
This pull request, where @rwjblue actually provided all the hints I needed to make this work. The trick is that the correct
ember-template-compiler
version is now hosted on bower. Raw files can be found here: https://github.com/components/ember. It is recommended to download both ember and ember-template-compiler from there, so versions would be synced. -
Once the basic HTMLBars started working, other stuff started breaking. Namely, all the old handlebars helpers. There’s supposedly a compatibility layer, but if you’re doing anything more ambitious, you’re better off rewriting them into htmlbars helpers.
-
Rewriting a helper into htmlbars comes down to changing all the
Ember.Handlebars.registerHelper()
calls intoEmber.HTMLBars.registerHelper()
. And then changing the method signature, which now takes 4 arguments:-
params
: array with the ordered arguments. All the stuff that used to be beforeoptions
-
hash
: what used to be atoptions.hash
, only simplified -
options
: the old options, stripped down of a few things -
env
: I think this is the old buffer/context that used to be in options, didn’t touch it
-
-
There are no longer contexts and types info for the values in
params
andhash
(ever since the 1.9 actually). Everything is now either a literal string or a stream (which you should check for). I still have no idea how to manipulate these streams, but it seems setting up ValueBinding still produces bound property, and that was good enough for my use case. -
If you are calling any built-in helper you need to call
helper.helperFunction
instead of justhelper
. Example:return Ember.HTMLBars.helpers.view.helperFunction.call(this, [App.MyView], hash, options, env);
That’s it so far. Speed increase feels about 50%, although I’m yet to run more elaborate tests.
Note: I suspect that most of this could have been prevented by finding the right articles or forum posts where this stuff is explained. However, if such things do exist, Google was unable to find them.