セッション オブジェクトは、グローバル (シングルトーン) レジストリです。それらを使用しない理由はたくさんあります (「なぜ (シングルトーン、グローバル オブジェクト、レジストリ パターン) (is|are) bad」をググってください。
Meteor では、状況はもう少し特殊です。Session オブジェクトは、変数をリアクティブに格納するための非常に簡単な方法です。これが、アプリケーションでグローバル変数を使用しない唯一の理由です。反応性が必要ないと仮定すると、それをグローバル変数にしますか? おそらくそうではありません。
セッションを誤って使用して、コード内のある場所から別の場所に変数の内容を取得しています (関連オブジェクトではない他の 2 つの方法の間の内容の目に見えない「神秘的な橋」です)。これは「Meteor」の方法でもクリーンな使用でもありません (上記の検索結果を参照)。それは簡単で汚い可能性です。
よりクリーンなアプローチ
これを回避する方法: 独自のリアクティブ変数を作成します。Meteor はそのためのすべての手段を提供しており、それを行うのは非常に簡単です。
(function () {
var currentProject;
var currentProjectDependency = new Deps.Dependency();
Meteor.Router.add({'/projects/:id', function(id) {
currentProject = id;
currentProjectDependency.changed();
return 'project';
}
Template.project.project = function() {
Deps.depend(currentProjectDependency);
return Projects.findOne(currentProject);
}
}());
現在、情報を保存するためにセッションを使用していませんが、反応性もあります。さらに、グローバル空間を汚染しません。最新リリースの Meteor では、クロージャが自動的に追加されることに注意してください。
この例は、複数のオブジェクト (コントローラーなど) にまたがる反応性を備えた、より複雑なユースケースに拡張できます。もう少し複雑な例として、私のナビゲーション パッケージを見てください。
セッションを使用する理由
では、なぜセッションが存在するのでしょうか。2 つの理由:
簡単にするために。Meteor は初心者に優しいように努力しています。私が説明したアプローチは、反応性とアーキテクチャーを理解しているため、もう少し複雑です。ほとんどのプロジェクトは、これを気にしないほど小さいです。
しかし、より大規模なプロジェクトでもセッションを使用できます。ページのリロードにまたがって情報を保存するには、他の方法では回復できませんでした。私の意見では、これがセッションを使用する唯一の理由です。セッションのコンテンツは、コードのプッシュによるページのリロード後も「保持」されます。これが悪いと考えられたら?いいえ。セッションの内容に依存するオブジェクトは 1 つだけだからです。情報を簡単に復元できるため、これはあなたの例には当てはまらないことに注意してください。