You can update your app back to what you had before. So if you were running Meteor version “1.0.5” before, you can switch to it by running meteor update --release 1.0.5. Or, if you have a snapshot in your git or any other VCS, you can check out an older revision.
Thanks. Actually, this has since been OBE. I am using 1.1 on PC now. I appreciate your response.
Having an @index is amazing! Been playing with this for a couple weeks & from what’s promised, it’s perfect. The only problem I see is that the basic context pattern is still a little messy. For example, let’s say we have a certain list:
{{#each suggestion in suggestions}}
<li>{{suggestion.name}}</li>
{{/each}}
Easy, clean, beautiful! But now, let’s say I want to do something really simple, like make the first item in that list active by default:
{{#each suggestions}}
{{>suggestion context=this idx=@index}}
{{/each}}
<template name="suggestion">
<li class="{{selected}}">{{context.name}}</li>
</template>
Template.suggestion.helpers({
selected: function() {
if (this.idx === 0) return 'active';
}
});
That blew up! I had to create a separate template, piece together the context, and, of course, the helper. I think the helper is unavoidable, but what would be nice is a way to access the @index from the parent template, or maybe the option to extend a context so I don’t have to pass in everything explicitly (this gets ugly when I have to pass in 5 or 6 variables to the child template). Any thoughts on how to clean up this pattern?
What is wrong with passing the value of @index to the child templates and then passing them to the helpers as arguments?
{{#each suggestion in suggestions}}
<li class="{{selected @index}}">{{suggestion.name}}</li>
{{/each}}
Template.suggestions.helpers({
selected: function (idx) {
return idx === 0 ? 'active' : '';
}
});
This seems to be a reasonable approach to me. Perhaps you were not aware of the fact that you can pass values to helpers?
1 Like
Wouldn’t the following work in this particular case?
{{#each suggestion in suggestions}}
<li class="{{#unless @index}}active{{/unless}}">{{suggestion.name}}</li>
{{/each}}
2 Likes
How is this coming along?
I think it’s coming out in the next release!
SUUUUUPER helpful! Thank you!
Any progress on this?
It is scheduled for the next release of Meteor.
1 Like
I’m actually getting an error now when I try to start meteor. Any ideas how to fix:
C:\Users\bdcon734\Documents\code\ltc>meteor
C:\Users\bdcon734\AppData\Local\.meteor\packages\meteor-tool\1.1.1-win.7\mt-os.w
indows.x86_32\tools\server\mini-files.js:18
if (p[0] === "\\" && (! partialPath)) {
^
TypeError: Cannot read property '0' of undefined
at toPosixPath (C:\Users\bdcon734\AppData\Local\.meteor\packages\meteor-tool
\1.1.1-win.7\mt-os.windows.x86_32\tools\server\mini-files.js:18:8)
at Object.convertToStandardPath (C:\Users\bdcon734\AppData\Local\.meteor\pac
kages\meteor-tool\1.1.1-win.7\mt-os.windows.x86_32\tools\server\mini-files.js:55
:12)
at Object.files.getHomeDir (C:\Users\bdcon734\AppData\Local\.meteor\packages
\meteor-tool\1.1.1-win.7\mt-os.windows.x86_32\tools\files.js:1165:13)
at defaultWarehouseDir (C:\Users\bdcon734\AppData\Local\.meteor\packages\met
eor-tool\1.1.1-win.7\mt-os.windows.x86_32\tools\tropohouse.js:30:43)
at Object.<anonymous> (C:\Users\bdcon734\AppData\Local\.meteor\packages\mete
or-tool\1.1.1-win.7\mt-os.windows.x86_32\tools\tropohouse.js:39:42)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)
at require (module.js:380:17)
C:\Users\bdcon734\Documents\code\ltc>@brett84c if you’re on Windows, the preview release for this feature might not work because it was published before the Windows port was done. The next official release of Meteor (probably 1.1.1) will have these features.
Ah, shoot. How do I remove this, since it’s not technically a package? Should I just revert my git to before it was added?
I hate that my work computer is windows and home computer is a mac, heh.
You can edit the file in .meteor/release to say 1.1.0.2. This should also be tracked by git.
Very nice feature to have. It’s nice to see more work being done on Blaze. 
I am trying to implement this, but I’m getting an error in the console saying, “No such function: test”. Here’s my code if you can help me where I went wrong. Thank you!
I’m curious, do we need to use the 1.2 RC to use {{@index}}?
Yes, I think that was stated on the update list.
1 Like
Just installed rc16
@index is running great Thanks for update!
Running the risk of sounding like a spoiled brat - Any chance of having a @first and @last?