Meteor Helpers 缓存游标
Meteor Helpers caching Cursors
我有一个包含 select 的模板,它使用户能够过滤显示在 table 上的集合中的某些对象。
我将 select 的结果存储在 ReactiveVar 中。然后我在查询中使用这个 ReactiveVar 来寻找一个助手 return 我的对象到模板。
模板代码
<select id="colorSelect">
<option val="getRed">getRed</option>
<option val="getBlack">getBlack</option>
</select>
<table>
{{#each Objects}}
/* create table */
{{/each}}
</table>
这是 JS
//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();
}
});
这一切似乎工作得很好,我的 table 根据 select 进行了被动调整。
我的问题是关于效率以及框架是否知道缓存我已经得到的游标。那么它会在每次用户更改 select 时执行 DB.find() 吗?
是否更有效率
1.做一个初步的发现
2. 然后过滤这个主要的原始数据(来自 fetch 调用的数组)
3. 最后return回到UI
然而,这样做似乎完全失去了反应性的任何优势,并且需要用 JS 重新排列 table。
或者...Meteor 是否只知道缓存我已经得到的游标(它甚至会产生性能差异吗 - 因为它是从 MiniMongo 中获取的..哪个 afaik 只是一个 JSON 对象)
这种将 reactiveVar 与 Helper 结合使用的模式是标准吗?
我会说你的代码非常可靠,这实际上是它如何完成的标准,所以不用担心那部分。
至于效率和缓存,重要的是要注意客户端已经在 minimongo
中保留了服务器数据、订阅的本地副本,所以只要您:
- 将此数据保持在最低限度;不要过度发布
- 不要经常重新订阅新数据从而破坏旧数据
你可以开始了。 :)
我有一个包含 select 的模板,它使用户能够过滤显示在 table 上的集合中的某些对象。
我将 select 的结果存储在 ReactiveVar 中。然后我在查询中使用这个 ReactiveVar 来寻找一个助手 return 我的对象到模板。
模板代码
<select id="colorSelect">
<option val="getRed">getRed</option>
<option val="getBlack">getBlack</option>
</select>
<table>
{{#each Objects}}
/* create table */
{{/each}}
</table>
这是 JS
//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();
}
});
这一切似乎工作得很好,我的 table 根据 select 进行了被动调整。 我的问题是关于效率以及框架是否知道缓存我已经得到的游标。那么它会在每次用户更改 select 时执行 DB.find() 吗?
是否更有效率 1.做一个初步的发现 2. 然后过滤这个主要的原始数据(来自 fetch 调用的数组) 3. 最后return回到UI 然而,这样做似乎完全失去了反应性的任何优势,并且需要用 JS 重新排列 table。
或者...Meteor 是否只知道缓存我已经得到的游标(它甚至会产生性能差异吗 - 因为它是从 MiniMongo 中获取的..哪个 afaik 只是一个 JSON 对象)
这种将 reactiveVar 与 Helper 结合使用的模式是标准吗?
我会说你的代码非常可靠,这实际上是它如何完成的标准,所以不用担心那部分。
至于效率和缓存,重要的是要注意客户端已经在 minimongo
中保留了服务器数据、订阅的本地副本,所以只要您:
- 将此数据保持在最低限度;不要过度发布
- 不要经常重新订阅新数据从而破坏旧数据
你可以开始了。 :)