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

core
41

@sashko, @slava: would you mind sharing your plans for Blaze?

42

We are currently working on a plan, hopefully we will be able to share it in the next week or two.

43

That is great, thanks!

44

Is there any reason why you format your code examples in such a weird way?

1 Like
45

@slava: I can explain everything. Where’s that weirdness?

46

Template tags look like handlebars block helpers and the lines are indented with like 30 characters of whitespace.

47

Oops. Should be fixed.

48

@slava, @sashko: some more ideas for unifying everything. No more context, just Template.data:

<!-- Args: dateOfBirth -->
<template name="myTemplate" dateOfBirth=TEMPLATE_ARG>
  {{ageObj=th_buildAgeObject}}    <!-- Add ageObj to template scope -->
  <p>Your sign is: {{ageObj.zodiac}} (click to display some cool stuff)</p>
</template>

Template.myTemplate.helpers({
  th_buildAgeObject: function() {
    var dateOfBirth = Template.scope().dateOfBirth;
    ...
});

Template.myTemplate.events({
  'click': function() {
    var ageObj = Template.scope().ageObj;
    ...
});
49

@Steve we are not considering adding any template arguments in this batch. Please stick to the original topic of let and each-in

50

Well, thanks for telling me I have been both lazy (I should have created another thread) and a drag :- )

Anyway, I think I made my point clear enough: the very notion of context is a re-factoring nightmare. In my opinion, it should be abandoned altogether (or at least people should be allowed not to use it at all).

The new features proposed in this thread title are nice-to-have, because they ease the pain caused by this problematic notion of concept, but they don’t address the crux of the issue.

51

This looks just like #let :slight_smile:

52

Sorry, my mistake. I have updated my sample code above (see the ‘click’ event). What I am suggesting here is to replace the notion of context by a notion of template scope, unified with Template.data.

53

This proposal doesn’t suggest unifying “template scope” with the “Template.data”. Often, people use the data context as the associated model for the template and not as the scope. This is the reason why we are moving towards having a separate scope per template, similar to scopes in JS functions.

54

Well, it seems I am having hard time explaining what’s in my mind…
However, “having a separate scope per template, similar to scopes in JS functions” is exactly what I’d like to have, so I am happy anyway and I can’t wait commenting and trying your first proposals.

1 Like
55

A quick stupid question - how do we revert back after updating? Not saying I need to, just wondering.

56

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.

57

Thanks. Actually, this has since been OBE. I am using 1.1 on PC now. I appreciate your response.

58

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?

59

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
60

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