It is not on devel
.
This is great, so much needed.
Typo in your post:
{{#each person in people}}
<p>{{person.name}} - {{@index}}</p>
{{/person}}
should be:
{{/each}}
thanks, fixed. The syntax highlighting is off and I didn’t notice that
P.S. Discourse smileys are terribly picked
I found something, which might be an issue or not:
You can use:
{{#each th_roles}}
{{> role role=this}}
{{/each}}
But this leads to an error (until you rename template ‘role’) :
{{#each role in th_roles}}
{{> role role=role}}
{{/each}}
Just need a confirmation:
With the #each in
syntax, you need to use #with
to set the context if you want to access the state of the variable from within an event handler, right?
{{#each author in authors}}
{{#with author=author}}
<button class="clickMe">Click Me</button>
{{/with}}
{{/each}}
'click .clickMe': function(event, template) {
console.log(this.author.name);
}
In this case it makes sense to me: template names and helpers and variables all share the same namespace. By writing {{> role role=role}}
you refer to the closest definition of ‘role’, in this case, a variable defined in #each
.
Right, this is not the prettiest thing though.
This is not pretty, but I prefer it over the old syntax anyway (find it more self-commented).
@slava Obviously spacebars is distinct from handlebars - but what was the reasoning behind diverging from the existing Handlebars Syntax- {{#each object as |value index|}}
(See Handlebars Source)
Thanks for pointing this out! To be honest, I had no idea this is the official Handlebars syntax. I saw it in the Ember “future plans” docs, but not in Handlebars. I was referring to this page: http://handlebarsjs.com/block_helpers.html. Even current Ember implementation implements #each foo in foos
, so this is at the very least, surprising.
@slava I’ve found handlebars is really poorly documented!
I just end up reading their unit tests to discover syntax.
After looking more into this and discussion this internally, here is what we found:
- Handlebars syntax is not well documented. We consider features described in their documentation to be the “released” and perhaps “official” features.
- Ember and Handlebars share the same Handlebars parser, although they have different syntax at this point.
- Handlebars still uses the older syntax of each:
#each things
that changes the data-context - Ember introduced the newer syntax similar to what we propose in this thread:
#each thing in things
that doesn’t change the data-context. - Ember, the new unreleased version, is proposing the newest syntax of
#each things |thing index|
, which is not really loved by Ember community in their PR. It is not released yet. - There is no a word for Handlebars for changing their syntax, but their parser implements all of them as it is needed for Ember.
I like the fact that Spacebars is a familiar syntax to anyone who used Handlebars but the divergence is inevitable, and we can see how Ember and Ractive already diverge.
@slava So, what does that mean for #each in
?
Also, it does appear in their official documentation (on the page you linked - search for #each users as |user userId|
)
@nathan_muir oh, to be honest, I didn’t see it there after looking like a month ago. Not sure if it is new, or I just generally assumed the page didn’t change.
Are you able to foresee a release version/date for this?
I don’t have an opportunity to work on Blaze all the time, this is why the process is moving slow. Right now, we are in the feedback-collection phase, but so far not a lot of people have replied to this thread. cc @dgreensp
I see. Thanks.
Can you recommend things we should specifically test / look out for? Or are there any specific areas that you are expecting feedback on?
I am curious to see if this syntax actually makes the development easier
and less confusing as it doesn’t modify the data context but introduces a
variable. As a side effect, it is harder to access such new variable inside
helpers or event handlers. A possible solution is to introduce a JS lookup
interface, I didn’t think about it when we implemented these new
constructs. I am looking for things like this.
Oh. My 2¢:
- I love the
each in
syntax. I find it much easier to read and follow. That may be because I am coming from a java world where official templating engines used that syntax. Anyway, I find it great and well worth the extra keystrokes while coding. - I am indiffirent to let. I could easily live with template helpers like I do know
- @index is a quite good addition, but it can already be achieved in a number of unintrusive ways. So, nice to have, can live without.
- The need for the extra
with
for getting the context in an event map… Well that kind of hurts. In fact, I’ve always foundwith
confusing and a last resort kind of tool.