【问题标题】:Meteor prevent re-loading data on each edit?Meteor 防止在每次编辑时重新加载数据?
【发布时间】:2013-12-17 06:43:43
【问题描述】:

我正在处理我的第一个 Meteor 项目 - 在完成 80% 的应用程序的情况下接管了其他人的代码。

我们有一个相当大和复杂的对象模型,有点像:

something: { ... }
attachments: [ {...}, {...}, ...]
another-thing: { ... },
....

它是使用加载的(所以我们使用的是LocalCollection.Cursor 而不是获取):

Inspections.findOne({_id: inspection_id})

此对象填充一个模板,该模板被拆分为几个单独的组件模板。

在这些组件模板之一中,用户可以更新各种属性。例如选择或取消选择附件:

Object.attachments[0].selected = true;

然后我们像这样更新(其中updatedAttachments 是更新后的附件数组):

InspectionOrders.update({ _id: inspection._id }, {
  $set: {
    attachments:updatedAttachments
  }
});

问题是附件(和一些其他属性)从 a 加载一堆其他数据,这可能需要一段时间。更改 select 状态需要 3-4 秒才能重新渲染,因为所有这些小附件都在重新下载。

我的问题:

  • 有没有一种方法可以处理更新此对象而不需要在每次更改时下载此数据?

  • 一般来说,将这个对象拆分成多个小对象是个好主意吗?如果父项的属性发生更改,那是否仍需要重新加载所有对象?

我尝试在{{#isolate}} 中扭曲部分模板,但没有任何区别。

编辑:

数据结构是这样的:

InspectionOrder
|
|- Attachments [file names]
|
|- Findings [keys]

页面加载或InspectionOrder 更新时。再次下载所有附件(图像文件)并再次填充所有结果(使用引用键)。

问题不在于更新速度。重新加载所有这些数据并没有改变。

【问题讨论】:

  • 您可能希望将附件存储在它们自己的集合中,并仅通过它们的 id 在检查对象上引用它们。 Meteor 将客户端上所有订阅的数据存储在 minimongo 数据库中 - 只有实际更改的文档才会发送到服务器或从服务器检索。
  • 除了将数据拆分为多个集合。有没有办法将模型更新限制在流星内的某个范围内?
  • 我对您的问题有点困惑 - 它只是一个非常非常大的文件吗?据我了解,目前 DDP 的实现只能发送整个文档。如果您的文档很大,例如数百 KB 到 MB,则可以解释更新时的延迟。我想我记得读过 DDP 的后续版本可能允许更精细的文档更新。如果您的文档那么大,无论如何我都会考虑规范化一点。
  • 没关系,根据当前规范:github.com/meteor/meteor/blob/devel/packages/livedata/DDP.md,文档更新应该只包含实际更改的字段。问题是,如果一个字段是一个数组或嵌套对象,则整个数组或嵌套对象都会通过网络发送(而不仅仅是更改的元素/属性)。因此,您的整个附件数组会在每次更新时传输。如果单个附件项目真的很大,那么您可能应该将它们规范化到它们自己的集合中。
  • 啊,你的更新澄清了这个问题。如果我没记错的话,浏览器应该缓存图像文件,因此不必重新下载它们。如果您使用以下命令运行流星应用程序是否有任何变化:meteor --release template-engine-preview-5.5

标签: meteor


【解决方案1】:

没有查看数据,我有点不清楚问题出在哪里,但您可以尝试以下几点:

更新更少的数据

您可以只更新已更改的属性,而不是设置整个附件数组。例如:

InspectionOrders.update({_id: inspection._id}, {$set: {"attachments.0.selected": true}});

这在给定文档有大量附件的情况下很有帮助。数据库执行起来会更快,但是,我不清楚服务器是否会将整个文档发布回用户。也就是说,这可能会有所帮助,但可能不会是一个大胜利。

发布更少的数据

在服务器上,您可以尝试在发布时有选择地从 InspectionOrders 中删除字段。例如:

Meteor.publish('inspectionOrders', function() {
  return InspectionOrders.find({}, {
    fields: {'attachments.hugeBinaryFile': 0}
  });
});

这有助于您在每个文档中发布大量额外数据。如果您在线传输的数据更少,您的文档同步速度会更快。

【讨论】:

  • 在当前的 DDP 规范中,更新发送单个字段,但在数组/对象的情况下它们不会精细发送部分字段。所以我认为第一个解决方案可能会导致发送到服务器的数据更少,但发送回客户端的数据量相同。
  • 我用更多信息更新了这个问题。问题不在于 Mongo 查找或更新的速度。事实上,一大堆其他连接的数据是使用引用键填充的。并且每次更新 InspectionOrder 对象时都会重新加载此数据。
猜你喜欢
  • 1970-01-01
  • 2014-03-04
  • 1970-01-01
  • 1970-01-01
  • 2018-07-21
  • 2013-06-16
  • 1970-01-01
  • 2014-02-16
  • 1970-01-01
相关资源
最近更新 更多