Can I subscribe to Meteor Session for reactive template render updates?

Question

Is there a way to subscribe to the Meteor Session object so that a reactive template view automatically renders when data is .set on the Session object? Specifically the ke

Answer 1

I don't think so.

Have a look at https://github.com/meteor/meteor/blob/master/packages/session/session.js. It's actually reasonably simple. The invalidation happens in lines 45-47. You'll see calling Session.set invalidates anyone listening to that key specifically (via Session.get) or to the new or old value (via Session.equals). Nothing in there about invalidating the session as whole.

On the other hand, considering how simple it is, it wouldn't be super hard to write your own data structure that does what you want. I'm not sure what your use case is, but it might make a lot of sense to separate it from the session.

Answer 2

Yes you can subscribe to Session values.

Take a look a the docs for autosubscribe:

http://docs.meteor.com/#meteor_autosubscribe

// Subscribe to the chat messages in the current room. Automatically
// update the subscription whenever the current room changes.
Meteor.autosubscribe(function () {
Meteor.subscribe("chat", {room: Session.get("current-room");});
});

This code block shows one way to use this. Basically any time the value of "current-room" is changed Meteor will update the views.

EDIT

I misunderstood the initial question and decided I need to redeem myself somewhat. I just did some tests and as far as I can tell you can currently only subscribe to collection.find() and session.get() calls. So you can't subscribe to the whole session object or even to the keys object.

However, you can set a Session value to an object this may not be the most elegant solution but this worked for me on keeping track of the keys object with some hackery to keep from getting a circular object error.

var mySession = {
  set: function(key, val){
    var keys = Session.keys,
        map = {};
   Session.set(key, val);

    for (var prop in keys) {
      if(!(prop === "keys")){
        map[prop] = keys[prop];
      }
    }
    Session.set('keys', map);
  }
};

This gives you something that looks a lot like original functionality and can help you keep track and update templates as you add or change Session values.

Here's my template helper (borrowed from previous answer):

Template.hello.keys = function() {
  map = [];
  keys = Session.get('keys');
  for (var prop in keys) {
    map.push({key:prop, value:keys[prop]});
  }
  return map
};

And here's the actual template:

<template name="hello">
  <div class="hello">
    {{#each keys}}
      {{key}} {{value}} <br />
    {{/each}}
  </div>
</template>

This way you can just call mySession.set("thing", "another thing") and it will update on screen. I am new to Javascript so someone please let me know if I'm missing something obvious here, or let me know if there is a more elegant way of doing this.

Answer 3

Unsure about subscribing to the session, but for the second part of your question, you can use this:

Template.hello.session = function () {
  map = []
  for (prop in Session.keys) {
    map.push({key: prop, value: Session.get(prop)})
  }
  return map
}

then in your template:

{{#each session}}
  {{key}} {{value}}
{{/each}}

Not sure if there's a more elegant way but it works.

Answer 4

While accessing the session object in this manner is doable .. You're not drinking the cool-aid.

In other words, Meteor excels in the respect of having publish/subscribe. Its not clear (to me) how much data you've got to put into the Session object before a browser crashes; I would rather not find out.

You would merely put all your session dependent code in a Deps.autorun() function to plug into subscriptions as mentioned in an earlier answer. Any time a session changes it'll modify the subscription; you can attach a ready callback, or use subscription.ready() checks to initiate specific actions, but ideally you'd structure your templates in a way that you could use rendered/destroyed functions, taking care to use {{isolate}}/{{constant}} when possible.

What you're getting at is kind of a difficult way to do something simple; and may not adhere to changes in meteor in the future; we can always be assured publish/subscribe will function as expected... Given Session is such a simple object.. whats to say someone designs something better shortly.. and it gets merged into meteor; and you're left with some weird workflow based on custom objects that may not break the Session; but may impact other parts of your interface.