Subscription Manager with template level subscriptions

1

When using template level subscriptions as described here you would do something like:

Template.notifications.onCreated(function () {
  this.subscribe("notifications");
});

This would mean that the subscription would be stopped when that template gets destroyed, correct? If so, that would mean that whenever that template gets created again (user clicks back button or some such), a new subscription would have to be created again.

I know that Subscription Manager exists to resolve that issue, so I could do something like

Template.notifications.onCreated(function () {
   // Subs = new SubsManager(); exists somewhere else
  Subs.subscribe("notifications");
});

but would this mean that the subscription doesn’t get stopped when the template is destroyed, because the template itself is no longer managing it? If so, is there anyway to get the best of both worlds? Have SubsManager caching subscriptions, but also allow the template to stop the subscription? What would the best practice for this be?

Please correct me if I have misunderstanding or am wrong about any of the above.

Thank you,

Mike

2

Subscription manager was originally created to prevent subs from being stopped from within iron:router. I believe that with template level subscriptions, Subscription manager is less useful than it used to be. I don’t have any reason to believe that you can’t use it with template subscriptions but I don’t think you need it.

3

No you are wrong.
Subscription manager is more than useful now.

Template level subs make a lot of subs and destroy as templates get destroyed. You can use subs-manager with templates with the pattern used by Telescope.

See: https://github.com/meteorhacks/subs-manager/issues/36#issuecomment-121163978

Video: http://www.telescopeapp.org/blog/telescope-weekly-2-subs-manager-fast-render/

1 Like
4

In subs-manager, it’ll manage subscriptions in it’s own scope. That’s the whole idea of it and it doesn’t respond to the running env. Due to that reason, you can’t stop individual subs. But can be controlled as a group.

Anyway, you can create as many as subs-managers for different subscription types (or whatever the group you wish)

5

Oh wow, TIL! Thanks @arunoda!

1 Like
6

I would really love to see an article or tutorial about how sub manager and template subscriptions can work together!

Also, if anyone tries it with React that would be interesting as well.

7

I think sacha did it pretty well. Not sure, he’s interested in doing that. @sacha are you?

I use it react all the time. Just replace Meteor.subscribe with SubsManagerInstance.subscribe.
It’s that easy.

I’m doing a react guide as well. I’ll add it to their.
Learned a lot.

8

That’s really awesome, looking forward to seeing that. Subscription management is one of the best reasons for pub/sub to be separate from minimongo queries, so it would be great to make it easy for people to take advantage of that.

9

I could write a post, but basically just replaced template.instance().subscribe() with subsManager.subscribe().

This does mean you can’t use Template.instance().subscriptionsReady() anymore though.

But I think it’s kind of an anti-pattern anyway. As Arunoda said, with template-level subscriptions, subscriptions get created and destroyed all the time, often multiple times per route. If you don’t cache them it leads to a pretty bad UX. So in a way, template-level subs should not be template-level :wink:

10

Well, it could make sense for us to have automatic caching. I believe that co-locating data fetching with view code makes sense, there are just some technical hurdles to overcome. Relay and GraphQL have one way; subscription caching is another.

11

I don’t know about the relay implementation. But I doubt it has caching. May be it can do with some add ons.

As far as I know, relay got a something like client side merge box. So, it’s a not the purpose of subscription caching. With that multiple components can use same set of data. Not sure how it manages when all the component for a given set of data gets destroyed.

GraphQL is reacts DDP I think. I understand it wrongly in earlier.