流星观察者重用：将更改我的发布返回查询不使用this.userId使我的观察者更可重用？

我有一个返回游标，看起来像这样的发布：流星观察者重用：将更改我的发布返回查询不使用this.userId使我的观察者更可重用？

// Publication RETURNS THIS QUERY 

Notepads.find({_id: notepadId, $or: [{userId: this.userId}, {'collaborators.userId': this.userId}], archived: false})

正如你所看到的查询是用户唯一的，因为它包括this.userId

我用this.userId在出版物作为一种形式的安全。如果您与该特定记事本关联，则只会返回数据。

在我的应用程序，可以有多人一个记事本合作。所以为了让观察者更加可重用，这个调整会对我的应用程序有所帮助吗？

// Optimized publication 

notepad = Notepads.findOne({_id: notepadId, $or: [{userId: @userId}, {'collaborators.userId': @userId}], archived: false}) 

if notepad? 
    // Optimized publication RETURNS THIS QUERY 
    return Notepads.find({_id: notepad._id, archived: false}) 
else 
    return

我认为这是观察者重用的手段。该发布返回与订阅该订阅的任何用户完全相同的查询。那么这是否正确，这个优化是否值得改变？

来源

2016-11-17 nearpoint

Quoting from kadira.io on How Observers are Handled in Meteor:

为了创建相同的观察员，您需要创建游标：

同一集合

相同的选择（查询）

同一组（包括分类，限制等）

在你的榜样，选择是不是对于不同的用户是相同的。

选择器是Object Literals并传递到.find调用之前进行评估。这意味着，{_id: notepad._id, archived: false}变得

{_id: 'myNotebookID', archived: false}，或
{_id: 'anotherNotebookId', archived: false}。

正如你所看到的，在你解决notepad._id之后，这些是不同的选择器，并且在传递给.find（）之前发生这种情况。

如果你的第一个数据库的查询返回了相同的记事本，因为你的第二个用户是第一个用户的笔记本电脑的合作者，你最终会得到相同的选择，和单光标/观测。然而，对于大多数应用程序来说，这可能不太适合优化，特别是（如@Khang所指出的），您将失去反应性。

所以，它是不一样的查询，它不会重用观察者，并且是不值得的变化。

来源

2016-11-18 01:37:02 JeremyK

嗨。我很困惑。你可以再看一下我所做的优化查询。我的确如你所说。如果第一次找到记事本，那么我返回光标'return Notepads.find（{_ id：notepad._id，archived：false}）'这是我对 – nearpoint

的更改，感谢您的详细解答！这是好东西。但我想澄清一点。如果许多用户在单个记事本（同一个notepad._id）上进行协作，那么这会不会改变呢？就反应性而言，代码的设置使得用户只有在他们是合作者时才会订阅。如果他们作为合作者被移除，而他们在记事本中，它仍然会同步记事本，并且在客户端上，我可以观看记事本并停止订阅，如果他们不再合作。因此，考虑到这些情况，现在值得改变吗？ – nearpoint

如果说典型的记事本协作介于5个用户之间，那么我认为这是值得的优化吗？ 10位用户？ 40用户？我想我宁愿不做优化，如果它几乎没有任何区别，我会放松反应 – nearpoint

没有与您的优化版本的问题就是它是没有反应。因为您使用Notepads.findOne作为安全检查，以确保用户有权访问该文档。

内部发布.findOne没有反应，比如说在执行发布时用户不能访问文档，因此没有任何内容被发送到客户端，那么用户被添加为协作者，但没有改变，因为发布将会重新发布重新运行。

来源

2016-11-18 02:04:38 Khang

流星观察者重用：将更改我的发布返回查询不使用this.userId使我的观察者更可重用？

回答

相关问题