can't (don't know how to) do basic loop operations with Ember/Handlebars or Htmlbars

[mgenev]

I'm trying to do this steps=5
{{#each steps as |step|}}

and I get an error that I can only do this for an array. So I have to go and create a junk array manually that only exists for this reason.

Then if I do loop over an array, I'm seeing that in handlebars I'm supposed to be able to output the index with {{@index}}, but that once again doesn't work.

So I basically have no way of performing one of the most fundamental functions of Javascript. Why is this? Am I doing it wrong or is it possible that there's a giant hole in the framework?

[trek]

This is an excellent question for Stackoverflow. We try to use Issues only to report and manage bugs.

[fivetanley]

Getting the index has indeed been a feature missing from the framework for a long time. Thankfully, Tim Evans implemented it in #10160.

You can read about enabling feature flags on canary builds here: http://emberjs.com/guides/configuring-ember/feature-flags/

After reading the above, the configuration you'll need is:

window.EmberENV = {
  FEATURES: {
    "ember-htmlbars-each-with-index": true
  }
};

Be sure to put this script tag before loading Ember itself. You can also add this in the FEATURES block in the pre-generated config/environment.js in Ember CLI.

[workmanw]

If you just need an array of sequential integers you could use a subexpression to generate a range: http://emberjs.jsbin.com/fuzuderopa/2/edit

Ember.HTMLBars.registerHelper('range', function(values) {
  var start = values[0];
  var count = values[1];

  var ret = [];
  for(var i = 0; i < count; i++) {
    ret.push(i+start);
  }
  return ret;
});

<ul>
  {{#each (range 0 10) as |item|}}
    <li>{{item}}</li> 
  {{/each}}
</ul>

[mgenev]

@fivetanley @workmanw thank you, very helpful, @trek not so much, when you make something fundamental that should take a minute to do, take an hour of trial and error and going to forums, it is a bug. This kind of issue and attitude just makes the framework less usable

[trek]

when you make something fundamental that should take a minute to do, take an hour of trial and error and going to forums, it is a bug.

Everyone has different levels of experience, so, in aggregate every feature of every library takes someone an hour of trial and error. StackOverflow is an excellent place to triage these types of questions, and the Ember community has an great answer rate. We always direct people questions to Stackoverflow which we think is the best location for this type of communication.

We use Issue specifically for tracking bugs/errors. You can read the Issue submission guidelines here: https://github.com/emberjs/ember.js/blob/master/CONTRIBUTING.md. A link to this is also posted on the top of the new Issue page.

Like most large projects, a significant amount of the community's volunteer team is spent reading and organizing issues. The part of the contributing document where we ask "If you are having difficulties using Ember.js or have a question about usage, please ask a question on Stack Overflow: http://stackoverflow.com/questions/ask?tags=ember.js" helps us prioritize errors that need fixing for the next release.

I'm glad someone was able to answer your question, but we try to communicate the venue where we think questions best the serve the community. On an issue, for example, we have no way to surface which of many answers it the best/correct answer. Answering questions on Issues also has a tendency to turn into long semi-training experiences. This is immensely useful for the person asking, but also fills every project collaborator's inbox with every new reply. This makes it harder for us to manage the project.

People (at least in the Ember community) also tend to search Stackoverflow and not Github Issues for problems like the one you experienced. Having the problem answered here means the next person who runs into this hurdle doesn't have the benefit of it being answered there.

If you could please re-post your question on Stackoverflow, I'm sure @fivetanley and @workmanw can also reply there, giving you the chance to select the best answer and letting future people upvote answers that worked for them.

[mmun]

I agree that this topic belongs on StackOverflow or IRC before creating an issue. There is no bug here, just a lack of understanding of how to compose two Ember tools for a specific use case.

In this case the two tools are the {{each}} helper and an array filled with numbers. The array could be handled as a static array, as a computed property or as a subexpression, as in Wesley's comment.

[mgenev]

@mmun you must have not read either my original message or @fivetanley's message about the index missing

So I have to go and create a junk array manually that only exists for this reason.

and

Getting the index has indeed been a feature missing from the framework for a long time. Thankfully, Tim Evans implemented it in #10160.

[mgenev]

@trek I don't buy this reasoning

Everyone has different levels of experience, so, in aggregate every feature of every library takes someone an hour of trial and error.

We're talking about something so fundamental in a programming language as a for loop with an integer as input. Denying usage of that simply makes using the framework harder. What is the merit of this "feature"?

That's the issue here. I'm not asking how to do this, in fact I provide the answer to that in the original post

So I have to go and create a junk array manually that only exists for this reason.

The fact that such a question has to be asked and that this is the solution is the issue.

[mmun]

This is a core principle of Handlebars. You can't add two numbers either, despite being a fundamental operation in programming languages.

Can you suggest how we can improve the documentation?

[mgenev]

Explaining what this principle is, what the merit of it is and what is the "proper" way of doing this is which if there is a merit would mean the better way of doing it.

If it isn't a better of way this, the principle is flawed and shouldn't exist.

[mmun]

What is flawed about {{#each myRange as |index|}} or {{#each items as |item index|}}? They are perfectly natural solutions to the problem. Why is the array "junk"? Functional languages do just fine without for loops.

[mgenev]

The flaw, imo, is that you need a redundant array in memory and another 5-6 lines of code. In other words, the principle makes it harder and less efficient to do the task.

[mmun]

In the future we could have {{each}} support generators to alleviate the memory concerns.

[ahacking]

@mmun thats a cool idea :)

Now that handlebars has the block syntax we can yield generator function values to the block :)

[trek]

@mmun pretty sure generators already just work in React.

[ahacking]

@trek yes React uses a DOM builder/JSX templates which allow full JS expressiveness and features and most importantly preserve JS context and scope. I prefer the power and lesser overhead of that approach compared to being forced into property/CP land to feed the rather simple handlebars templates.

There are for's and against both approaches, I've seen it said that handlebars templates are friendlier for designers if your workflow lets them edit your application templates, but even that has severe limits as you can't expect to allow the designer to refactor the view and make changes willy nilly unless they understand all of Ember's and your apps specific naming conventions. Refactors also require developer involvement as it will likely result in a change to stuff within the moustaches as well.

Ideally the Ember framework should allow both, I'm certainly interested in having a DOM builder rendering capability to support native JS/JSX-like apporaches, preferably layered within Embers core, and failing that via an add-on. The new isomorphic support may make this much easier to do with injectable renderers, but I haven't looked at the details.

[typeoneerror]

Ya'll want to display an index in a looped view, use css counters instead of doing them programmatically with ember: https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Counters?redirectlocale=en-US&redirectslug=CSS%2FCounters. Supported all the way back to IE 8 so no excuse not to: http://caniuse.com/#search=counter