Help test the preview release with new upcoming Blaze features (#each-in, #let, @index)

It is not on devel.

This is great, so much needed. :smile:

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 :frowning:

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 found with confusing and a last resort kind of tool.