Meteor Helpers 缓存游标答案

【问题标题】：Meteor Helpers caching CursorsMeteor Helpers 缓存游标
【发布时间】：2019-12-18 19:55:31
【问题描述】：

我有一个模板，其中包含一个选择，它使用户能够过滤集合中显示在表格上的一些对象。

我将选择的结果存储在 ReactiveVar 中。然后我在查询中使用这个 ReactiveVar 来让 Helper 将我的对象返回到模板。

模板代码

<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();
    }
});

这一切似乎都很好，我的表格会根据选择进行反应性调整。我的问题是关于效率以及框架是否知道缓存我已经得到的游标。那么，每次用户更改选择时，它会从字面上执行 DB.find() 吗？

是否更有效率 1.做一个初步的发现 2. 然后过滤这个主要的原始数据（来自 fetch 调用的数组） 3.最后返回UI 但是，这样做似乎完全失去了反应性的任何优势，并且需要使用 JS 重新排列表格。

或者...Meteor 是否只知道缓存我已经获得的游标（它是否甚至会产生性能差异 - 看到它从 MiniMongo 中获取它..which afaik 只是一个 JSON 对象）

这种将 reactiveVar 与 Helper 结合使用的模式是标准吗？

【问题讨论】：

标签： javascript mongodb caching meteor

【解决方案1】：

我想说你的代码非常可靠，这实际上是它如何完成的标准，所以不用担心那部分。

至于效率和缓存，需要注意的是客户端已经在minimongo中保存了服务器数据、订阅的本地副本，所以只要你：

将此数据保持在最低限度；不要过度发布
不要不断地重新订阅新数据从而破坏旧数据

你可以走了。 :)

【讨论】：

谢谢！当客户端从 MiniMongo 中取数据时，你知道它是否只是一个简单的 key-value 检索吗？从我读过的所有内容来看，这就是它的样子。特别是考虑到 MongoDB 本身只是一个文档存储（据我所知）
是的，差不多。 docs.meteor.com/api/collections.html ``` Minimongo 实例已创建。 Minimongo 本质上是纯 JavaScript 中 Mongo 的内存中非持久实现。它用作本地缓存，仅存储此客户端正在使用的数据库的子集。对这些集合的查询（查找）直接从此缓存中提供，无需与服务器对话。 ``` 这是一个更简单的 MongoDB 版本，允许在客户端使用与后端类似的 API 轻松进行数据操作。