Meteor 模板级别的个人订阅,我滥用模板级别订阅的情况有多糟?

Meteor 模板级别的个人订阅,我滥用模板级别订阅的情况有多糟?,meteor,handlebarshelper,Meteor,Handlebarshelper,我变懒了,添加了以下帮助程序: // Given a userId, show the username Handlebars.registerHelper('username', function(userId) { // This seems extremely wasteful Template.instance().subscribe('user', userId); var user = Meteor.users.findOne({ _id: userId }

我变懒了,添加了以下帮助程序:

// Given a userId, show the username
Handlebars.registerHelper('username', function(userId) {
    // This seems extremely wasteful
    Template.instance().subscribe('user', userId);

    var user = Meteor.users.findOne({ _id: userId });
    if (user) {
        return user.username;
    }   
    return "";
});
是的,对于模板级订阅,对我的原型非常有用!我找不到任何人反对这个想法,但也许那是因为它太愚蠢了以至于没有人会考虑这么做。你对这种款式有经验吗?你能推荐一下吗


我特别担心订阅量,以及它们可能导致的大量重新渲染。

在我看来,这不是最明智的做法。当你需要的时候,为什么要重新发明轮子 已经定义了此类帮助器

{{currentUser}}


需要用户名
{currentUser.username}

一般帮助程序的想法可能没有那么糟糕,但我会将订阅和名称检索分开,使订阅只运行一次:

Handlebars.registerHelper('userSubscribe', function(userIds) { // make userIds an array
    Template.instance().subscribe('users', userIds); // change your publishing function to take the array
});

Handlebars.registerHelper('userName', function(userId) { 
    var user = Meteor.users.findOne({ _id: userId });
    if (user) {
        return user.username;
    }   
    return "";
});
然后,每个模板负责发送它实际想要订阅的用户列表。为了简单起见,假设您有一个posts集合,其格式如下:

{author: user_id, commenter: user_id, text: String}
那么您应该能够像这样使用它:

// JS
Template.myTemplate.helpers({
  getMyUsers: function() { return [this.author, this.commenter]; }
});

// HTML
<template name='myTemplate'>
  {{userSubscribe getMyUsers}}
  The author is {{userName author}} and the commenter is {{userName commenter}}
</template>
//JS
Template.myTemplate.helpers({
getMyUsers:function(){return[this.author,this.commenter];}
});
//HTML
{{userSubscribe getMyUsers}}
作者是{{userName author}},评论者是{{userName commenter}}

它可能仍然不理想,但应该只重新呈现一次,而不是在数据到达客户端时为每个要查找其名称的用户重新呈现一次。

这只适用于当前用户。从他的代码来看,他似乎希望它适用于任意用户。我能想到的唯一用法是当Id列出用户或帖子或其他内容时,想要获得用户名(所有者名称)。我需要到处显示用户名,以前的解决方案是在模板加载时提取所有用户Id并订阅列表。我在这里做的比较简单,但它可能无法扩展,所以我在问这个问题。我怀疑它可以扩展得很好,因为订阅只是订阅一个集合。同一集合上的多个订阅,无论它们是否重叠,都不会导致多次从服务器获取相同的数据。流星很聪明@Sandervandenaker,订阅越多,服务器所做的工作就越多。弄清楚哪些数据是重复的或不是重复的需要时间。好吧,至少它是有效的。如果你有一个包含50个唯一用户ID的列表,我不会推荐它(会创建50个不同的订阅!)。是的,问题是在呈现模板时启动50个订阅有多糟糕:-)我不知道它有多糟糕(对我来说听起来很糟糕),但是如果我是你,相反,我会尝试将用户名附加到从中获取用户ID的文档中。当然,以这种方式复制数据是不好的,但这是一种权衡。希望其他人能给你一个更准确的答案。对于复杂的布局来说,这是一个非常强大和有用的功能,但它真的不应该以这种方式使用。虽然Meteor可以为您提供超能力,但如果您不小心实现它们,您将度过一段不愉快的时光。是的,在我变得懒惰之前,我也做过类似的事情:-)