Blaze Template Event - How to Get @index?


#1

My template lists “line items” within “my order”

While the object myOrder contains a unique _id, the objects within the array “lineItems” might not have unique attributes:

<template name="receive">

   {{#with myOrder}}

   <h2 title="Unique Order ID: {{_id}}"></h2>

   <table>

       {{#each lineItems}}

         <tr>
           <td class="col-md-2">{{item_code}}</td>  // not a unique code
           <td class="col-md-4">{{item_description}}</td> // not a unique name
           <td class="col-md-2">{{item_quantity}}</td>         
           <td><button class="btn btn-default" id="button" >Edit</button></td>  
         </tr>

       {{/each}}    
  
     </table>  
  
    {{/with}}

</template>`

I would like to be able to edit a line item by clicking the button on the table

In order to edit the correct line item, I need to identify it uniquely within the array lineItems.

The value this.index returns undefined

I was thinking of using the {{@index}} attribute / value that exists on the template - perhaps by passing it back into a custom data attribute:

<td><button class="btn btn-default" id="button" data-index="{{@index}}" >Edit</button></td>

However, this seems regressive and not the ‘Meteor way’. Besides which, as I slowly switch to React, this does not seem future-proof.

Template.myOrder.events({
    'click .#button': function (e) {
    console.log('clicked edit')
    console.log(this.index);  // returns undefined
    console.log($(e.target).data("index")) // returns the index, but is this the best approach?       
  }
})

Any suggestions as to the correct approach here?


#2

For me, it’s perfectly normal to use data-attributes. You need to distinguish different items, so either you make it at code-level (thru closures, etc), or you add a piece of data to caller itself.

But idea to use index variable for this sounds bad. You should have some unique identifiers for order items. Why isn’t item code unique? What is unique, then?


#3

Thanks. item code is not unique in this object becuase the same item can be added to the list more than once. Think of the supermarket checkout where items can be scanned one at a time (in no particular order) or else added in multiples. Only the index, therefore, is unique.


#4

I second the use of the data attribute. Back in the day, people were clamoring for the @index, and while it should maybe be baked in a bit more thoroughly (like you’re alluding to with your this.index, I’ve never had an issue using it passed as a data attribute.


#5

Is the ungrouping of the same-id items the requirement or just the realisation issue?
In Relation DB theory use can use composite indexes, like ‘item.id – addTime’. It’s a very bad idea to use index as identifier. Just think about sorting, list editing and all the other interactions that can be done to list. Only if you are totally and completely sure, that this list will remain forever in this sorting and filtering and is never editable, you may use index as identifier.