I’ve been enjoying the recent discussion and thoughts on subscription management. Especially template subscription in meteor 1.0.4 and the musings of @arunoda on subscription management.
I typically find that the subscriptions I make fall into one of three different priorities:
- The top priority are subscriptions I need to render a layout/ minimally functional page
- The next are subscriptions I need to make a widget work that is embedded within said page, but doesn’t necessarily have to be ready at page load
- The third are subscriptions I make because I anticipate the user will need them at some time even if they don’t need them immediately (basically to make the app respond in a more native way)
waitOn router based subscriptions work great for the 1st. Template subscriptions and/or waitOn router subscriptions are perfect for the 2nd. But I wanted to get some thoughts about a potential solution for the 3rd.
Would it work to use subs-manager with unblock in the following way.
- Do a Tracker.autorun looking for a valid user.
- As soon as the user exists do a subscribe to a publication that provides all/most of the collections that user might need in the future. This publish would be non-blocking.
- Later on, if that data becomes critical do a subscribe to a similar publication that will return the critical data but without unblocking/yielding.
- I would pump all of these into a subManager() instance.
Some questions that come to mind are:
- If whether to block or not is a parameter passed to the publication, what would happen when calling the same subscription twice, but once with this.unblock being true and later being false (especially if the unblocked version hasn’t finished)?
- Other strategies to pull largish amounts of data into client side collections without creating blocking DDP connections that could interfere with smaller subscriptions?