I have a Template that features a select element allowing users to filter through a collection of Objects displayed on a table. The result of the select is stored in a ReactiveVar, which is then utilized in querying a Helper to retrieve the Objects for the Template.
Template Code
<select id="colorSelect">
<option val="getRed">getRed</option>
<option val="getBlack">getBlack</option>
</select>
<table>
{{#each Objects}}
/* create table */
{{/each}}
</table>
JavaScript Code
//onCreated initializing Template ReactiveVar for Object's Color
Template.Object.onCreated(function() {
this.color = new ReactiveVar("");
});
//event for changing 'color' based on select option
Template.Object.events({
'change #colorSelect'(e, template) {
const target = e.target;
const color = $(target).val();
template.color.set(color);
}
});
//Helper method to return Objects
Template.objects.helpers({
Objects: function() {
const color = Template.instance().color.get();
return Objects.find({foo:bar, color:color}).fetch();
}
});
The functionality works effectively as the table reacts dynamically to the select options. However, I am concerned about the efficiency and whether the framework caches previously retrieved cursor data when a user changes their selection.
One possible approach could be: 1. Conduct an initial find query 2. Filter the main original dataset (an array from fetch call) 3. Return the modified data to the UI Yet, this method might sacrifice reactivity and necessitate table rearrangement with JavaScript.
Another question arises - does Meteor automatically cache cursors or is there a performance difference since it pulls data from MiniMongo, essentially a JSON object?
Would you consider using a reactiveVar paired with a Helper as a standard pattern?