2016-08-09 20 views
0

私はmeteor.jsサーバー上でこれをruningています:Meteor.js onStopイベント内でuserIdを取得する方法は?

Meteor.publish('games', function(){ 

    this.onStop(function() { 
     Meteor.call('leaveQueue'); 
    }); 

    return Games.find({ player: this.userId }) 
}); 

ユーザーがサブスクリプションを停止すると、それはmethods.js上で、この関数を呼び出します。

Meteor.methods({ 

    leaveQueue:function(){ 
     console.log(this.userId); 
    } 

}); 

それがnullとしてログインしますuserId .. コンソールでMeteor.call( 'leaveQueue')を使用してフロントエンドから呼び出すと、ユーザーIDが正しく記録されます。

私はconsole.log(Meteor.userId)とconsole.log(Meteor.userId())をすべて試してみました。

何が起こっている可能性がありますか?

答えて

0

Meteorでは、サーバー側の別のメソッドからメソッドを呼び出し、適切なコンテキストを維持できます(userIdconnectionなどはすべて元のメソッド呼び出しから取得されます)。しかし、メソッドをパブリッシュ関数から呼び出す場合はそうではありません。 Meteor.callをパブリケーション内から作成すると、呼び出されたメソッドは現在のDDP接続からの詳細を(DDP._CurrentInvocationの内部を参照して)抽出しようとします。これらの詳細は存在しないため、呼び出されたメソッドはそれらを保持できません(詳細については、ddp-server/livedata_server.jsのソースを参照してください)。私はユーティリティを呼び出すことによってonStopコールバックでuserIdを使用してメソッドのコードを実行することをお勧めしたい

Meteor.publish('games', function games() { 
    this.onStop(() => { 
    // This will log the proper userId 
    console.log(this.userId); 
    }); 
    return Games.find({ player: this.userId }) 
}); 

:言われて、あなたの出版物のonStopコールバックで現在userIdを取得することができること

関数ではなくメテオ法である。コードの重複を避けたい場合は、Methodの共通コードをユーティリティ関数に抽出し、両方の場所でそれを活用することができます。例:

// Stored in a utility file somewhere 
function doSomethingCommon(userId) { 
    // Do something ... 
} 

Meteor.methods({ 
    leaveQueue() { 
    doSomethingCommon(Meteor.userId()); 
    } 
}); 

Meteor.publish('games', function games() { 
    this.onStop(() => { 
    doSomethingCommon(this.userId); 
    }); 
    return Games.find({ player: this.userId }) 
}); 
関連する問題