this
SubsCache.subscribe 'posts'

gets passed to the publication like this:
{ subscriptionId: '4FHxbDWHRdFufDi2e' }

my publication handles different params
Meteor.reactivePublish "posts", (orgId, limit, starredOnly, collectionId) -> ...

but in this case I don't set any params for the subscription. Yet, subsCache adds params which are being passed.
orgId { subscriptionId: '4FHxbDWHRdFufDi2e' }

When doing this:

subs = new SubsCache({
    expireAter: -1,
    cacheLimit: -1
});

The result is
SubsCache {expireAfter: 5, cacheLimit: -1, cache: Object, allReady: ReactiveVar}

And this needs to be done to set expireAfter to -1:
subs.expireAfter = -1;

I think this is incorrect behaviour.

subsMgt = new SubsCache({
  expireAter: 5,  // minutes
  cacheLimit: 10
});

// Inside `autorun` inside `onCreated` callbacks
this.autorun(function () {
    var listId = FlowRouter.getParam('_id');
    if (listId) {
      self.listSub = subsMgt.subscribe('list', listId);
    }
  });

// Here's another
this.autorun(function () {
    if (Session.equals('listIsLoaded', true)) {
      var listItem = getListItem();
      if (listItem && listItem.someField) {
        self.listItemSub = subsMgt.subscribe('otherStuff', listIem.someField);
      }
    }
  });

If I change the cacheLimit to 1, the page will show the data and then the data will disappear because when I go to the list route, it will subscribe to the list, and find the last recently visited list item and go to it and subscribe to that, and once that happens, cache limit is hit and the data gets wiped for some odd reason.

Workaround right now is to set cacheLimit to -1 and manually stopping previous subscriptions.

With subs-cache 0.1.0 and meteor 1.2 or 1.3, it appears that the allReady reactive variable is not successfully set when subscriptions become ready.

An idea that was inspired by redis-oplog, why not have a parameter that allows us to keep using Meteor.subscribe and it gets redirected to meteor-subs-cache. This would make it BW compatible and easy to bolt on for all users. Maybe have SubsCache.origSubscribe to refer to the old one if needed.

The tests are already running and I added a .travis file a while ago. It would be great to include a CI service like Travis in order to get automatic builds on new pull requests so it is clear to everyone if a new PR passes the tests or not.

First, I want to say that I love this package and use it all my projects. Combined with PublishComposite, it has made a significant improvement to the performance of my projects.

But I noticed today that whenever any subs-cache subscription expires, the current template gets rerendered.

In my case, after a template is rendered, I do a scroll to top, and call an unveil function. I noticed after visiting several paths, then waiting for a backlog of subs-cache subscriptions to expire, that my current page was rescrolled to the top as each subs-cache expired.

I am wondering why the current template is rerendered, as presumably it already has all the data it needs from its own template subscriptions.

Is there a way to disable the rerenders triggered by the subs-cache subscription expiries? Or, perhaps can you suggest a way I can detect that the template has already been previously rendered and i can bypass my scroll-to-top function?

Thanks

Hi, great package. But it seems it can't handle subscription params? Because when I do something like this:

SubsCache.subscribe 'singlePost', id

it will return the same subscription from cache even when id changes.

I tried several ways to pass subsmanager.subscribe to this.register, and it broke.

var subs = new SubsCache(5, 15)
var subscribe = subs.subscribe
FlowRouter.route('/', {
  name: 'BLOCKRAZOR',
  subscriptions: function () {
    this.register('approvedcurrencies',subscribe("approvedCurrencies");
  },
  action() {
    BlazeLayout.render('desktop', {
      main: 'returnedCurrencies',
      left: 'menu'
    });
  }
})

Passing invoking subs.subscribe within this.register also broke.
this is the error message on client with fast render reporting same issue on server:

TypeError: Cannot read property 'apply' of undefined
    at SubsCache.subscribe (SubsCache.js:85)
    at Route.subscriptions [as _subscriptions] (routes.js:57)
    at Route.callSubscriptions (staringatlights_flow-router.js?hash=54561903308af27a237544b4c13ed49f3776b07e:896)
    at staringatlights_flow-router.js?hash=54561903308af27a237544b4c13ed49f3776b07e:597
    at Tracker.Computation._compute (tracker.js?hash=997515fa2d5b0530ba07741da556c4b36963ef3b:339)
    at Tracker.Computation._recompute (tracker.js?hash=997515fa2d5b0530ba07741da556c4b36963ef3b:358)
    at Object.Tracker._runFlush (tracker.js?hash=997515fa2d5b0530ba07741da556c4b36963ef3b:532)
    at Object.Tracker.flush (tracker.js?hash=997515fa2d5b0530ba07741da556c4b36963ef3b:483)
    at Router._invalidateTracker (staringatlights_flow-router.js?hash=54561903308af27a237544b4c13ed49f3776b07e:659)
    at afterAllTriggersRan (staringatlights_flow-router.js?hash=54561903308af27a237544b4c13ed49f3776b07e:271)

After adding the package to my project, the server crashes with the following error:

W20161215-20:21:24.603(1)? (STDERR) ReferenceError: Mongo is not defined
W20161215-20:21:24.603(1)? (STDERR)     at packages/ccorcos_subs-cache.js:288:18
W20161215-20:21:24.603(1)? (STDERR)     at packages/ccorcos_subs-cache.js:292:4
W20161215-20:21:24.603(1)? (STDERR)     at packages/ccorcos_subs-cache.js:351:3

Hi there!

Has anyone figured out a way to change a subscription parameters after a first init? Like working with pagination. For now, I'm overriding the subscription object in each autorun, causing templates to keep reference to previous object (that's how I understand the issue though) and not updating when the new subscription is created.

My workaround is to create a reactiveVar 'ready' that I set to false every time I update parameters, and set to true in a sub.onReady() callback. Not very complicated, but I'd prefer a more clean way to manage it.

Didn't find anything in docs, issues or in source code. Thanks :)

Callstack:

Error: Can't set timers inside simulations
    at withoutInvocation (timers.js:5)
    at bindAndCatch (timers.js:13)
    at Object._.extend.setTimeout (timers.js:29)
    at Object.SubsCache.SubsCache.subscribeFor.cachedSub.delayedStop (subsCache.coffee:89)
    at subsCache.coffee:85
    at tracker.js:263
    at Object.Tracker.nonreactive (tracker.js:560)
    at Tracker.Computation.invalidate (tracker.js:262)
    at Tracker.Computation.stop (tracker.js:279)
    at null.<anonymous> (view.js:203)

Hi there,

I am enjoying the subs cache package very much enabling me to speed up my app and reducing server load.

Problem

However, while updating my app to Meteor 1.3 modules I encountered, that this package has no export declaration in the package.js. So this package is not usable as a module.

Potential solution

Just add following statement to package.js:
api.export("SubsCache");

I'll create a pull request for that one...

Regards,
Icereed

this is by far not the last package which relies on underscore, but it's definitely not really necessary here 🔍

I'll create a pr after the formatting one is merged ;)

it's will return a tracker, not susbcription called inside right?

Hi @ccorcos, I'm thinking of using your package in a mobile app (meteor-cordova app), already in pre-production.

I had 2 main problems to solve in this app:

• Treat static, potentially big collections outside of meteor livedata package (no pub/sub): got this with the DumbCollections package;
• Try to reuse subscriptions between offline/online transitions, even when the browser refreshes. This is to avoid the overhead caused by reloading all data associated to subscribed collections on an offline/online transition (my users may be in zones with a poor network coverage, experiencing many reloads in a short intervals of time)

This last issue is giving me some work. It's a hard problem to solve. I though I could hold on to the subscription handle, save it in local storage and then find a way to reuse it like this:

//subsHandle holds the subs object before refresh
// after refresh, I could hold on to it like:
subsHandle = Meteor.subscribe(...)

But it's not that simple. Do you think there's a way to achieve this?

Thanks

I'm getting these errors and have no idea why.

Uncaught TypeError: this.ready is not a function
SubsCache.SubsCache.subscribeFor.cachedSub.onReady @ subsCache.coffee:72

So I've been loggin this out, and in some cases @ doesn't refer to a subscription, but to something else. It could be related to Iron Router onWait, because I"m waiting for subscriptions like this:

    waitOn: ->
      [ 
        SubsCache.subscribe 'userDirectory',
        SubsCache.subscribe 'posts',
        SubsCache.subscribe, 'singlePost', @params.id
      ]   

so this works when

• I navigate from another route, but when loading this route directly I get this @ready() is not a function error.
• I use Meteor.subscribe. As soon as I change to SubsCache I get this error

Any ideas?

When the cache overflows SubsCache doesn't only stop subscriptions that have been held back, but may stop subscriptions that have not been stopped at all. It should instead only stop subscriptions that have had stop called on them, but have not yet actually been stopped because of the caching.

The current behaviour is surprising and does not conform the the documented behaviour: "cacheLimit is the max number of subscriptions to cache".

Sample code below with onReady callback goes into an infinite AUTORUN loop:

Template.users.onCreated(function() {
    const template = this
    template.usersReady = new ReactiveVar(false)
    template.userLimit = new ReactiveVar(10)
    template.autorun(function() {
        console.log('AUTORUN')
        const subUsers = subsCache.subscribe('users', template.userLimit.get(), {
            onReady: function () {
                template.usersReady.set(true)
            }
        })
    })
})

The code below does not:

Template.users.onCreated(function() {
    const template = this
    template.usersReady = new ReactiveVar(false)
    template.userLimit = new ReactiveVar(10)
    template.autorun(function() {
        console.log('AUTORUN')
        const subUsers = subsCache.subscribe('users', template.userLimit.get())
        if (subUsers.ready()) {
            template.usersReady.set(true)
        }
    })
})

Consider a page with two independent sections (A and B) that both make a subscription with the same arguments.

1. A loads and creates subscription a.
2. B loads and creates subscription b (which SubsCache combines with a).
3. A unloads, stopping a.

Observed: at this point, the SubsCache subscription is delayedStoped. After the timeout, the real subscription is stopped, clearing the data that B is using.

Expected: the subscription is not stopped until b is stopped.

I am experiencing the following exception when using SubsCache in conjunction with Iron Router:

Exception in queued task: Error: Can't set timers inside simulations
    at withoutInvocation (http://10.1.1.50:3000/packages/meteor.js?43b7958c1598803e94014f27f5f622b0bddc0aaf:434:13)
    at bindAndCatch (http://10.1.1.50:3000/packages/meteor.js?43b7958c1598803e94014f27f5f622b0bddc0aaf:442:33)
    at Object._.extend.setTimeout (http://10.1.1.50:3000/packages/meteor.js?43b7958c1598803e94014f27f5f622b0bddc0aaf:458:23)
    at Object.SubsCache.SubsCache.subscribeFor.cachedSub.delayedStop (http://10.1.1.50:3000/packages/ccorcos_subs-cache.js?6a3225527386ddcfc7167b4226cf4ccde60559c2:165:44)
    at http://10.1.1.50:3000/packages/ccorcos_subs-cache.js?6a3225527386ddcfc7167b4226cf4ccde60559c2:156:30
    at http://10.1.1.50:3000/packages/tracker.js?6d0890939291d9780f7e2607ee3af3e7f98a3d9c:296:31
    at Object.Tracker.nonreactive (http://10.1.1.50:3000/packages/tracker.js?6d0890939291d9780f7e2607ee3af3e7f98a3d9c:593:12)
    at Tracker.Computation.invalidate (http://10.1.1.50:3000/packages/tracker.js?6d0890939291d9780f7e2607ee3af3e7f98a3d9c:295:15)
    at Tracker.Dependency.changed (http://10.1.1.50:3000/packages/tracker.js?6d0890939291d9780f7e2607ee3af3e7f98a3d9c:421:30)
    at http://10.1.1.50:3000/packages/minimongo.js?af9eb9d7447544ca9b839a3dcf7ed2da2209b56c:415:13
debug.js:41

Exception in callback of async function: Error: 

You called wait() after calling ready() inside the same computation tree.

You can fix this problem in two possible ways:

1) Put all of your wait() calls before any ready() calls.
2) Put your ready() call in its own computation with Deps.autorun.
    at Iron.utils.assert (http://10.1.1.50:3000/packages/iron_core.js?d966a1f70c94792fd94c8a155bdbef9bec5e0047:81:11)
    at http://10.1.1.50:3000/packages/iron_controller.js?b02790701804563eafedb2e68c602154983ade06:87:5
    at Array.forEach (native)
    at assertNoInvalidationLoop (http://10.1.1.50:3000/packages/iron_controller.js?b02790701804563eafedb2e68c602154983ade06:86:14)
    at WaitList.wait (http://10.1.1.50:3000/packages/iron_controller.js?b02790701804563eafedb2e68c602154983ade06:125:3)
    at Controller.wait (http://10.1.1.50:3000/packages/iron_controller.js?b02790701804563eafedb2e68c602154983ade06:442:20)
    at eachWait (http://10.1.1.50:3000/packages/iron_controller.js?b02790701804563eafedb2e68c602154983ade06:439:12)
    at Array.forEach (native)
    at Function._.each._.forEach (http://10.1.1.50:3000/packages/underscore.js?0a80a8623e1b40b5df5a05582f288ddd586eaa18:156:11)
    at Controller.wait (http://10.1.1.50:3000/packages/iron_controller.js?b02790701804563eafedb2e68c602154983ade06:438:7)

http://10.1.1.50:3000/packages/ccorcos_subs-cache.js?6a3225527386ddcfc7167b4226cf4ccde60559c2:156:30 corresponds to subsCache.coffee:85.

My Iron Router subscription looks like:

Router.route('/ticket/:_id', {
    name: 'ticketScreen',
    waitOn: function () {
        return [
            singleSubs.subscribe('ticketById', this.params._id),
        ];
    },
    data: function() {
        return Tickets.findOne({_id: this.params._id});
    },
});

and the exception happens when the document is updated from within the page (but not if it's updated somewhere else). For example:

Tickets.update('RjfW8d8Q93MupLXfJ', {$set: {notes:"yolo"}})

clearAll() does not clear the expiration timeout of the subscriptions.

We discovered that subscriptions started inside an autorun are stopped when Tracker is stopped.

This is not what we expected and was causing errors in our app.

Is it possible to add a param with the subscription to indicate if it has to be stopped or not? Or something similar...
Now autoruns are stopped when templates are destroyed, so maybe there's no need for this convenience.

Thanks

Hello,

Is there any chance to convert code to JavaScript?

In that case, we can maintain it at my company. We use your component in one of our biggest project, so we will have it up and running for quite long time. Must say that we do not use CoffeScript at all.

Let me know what you think.

And thanks a lot for your amazing job.

eslint might be overkill, but would you accept a pr applying at least prettier styles to the package?

https://github.com/ccorcos/meteor-subs-cache/blob/master/src/SubsCache.js#L2

Hey,
I have a problem with the recent version of this package.
The problem is, that subs-cache updates the subscription if a paramter changes (except first param).
If I have two subscriptions on the same page, the last called subsribe will update the first one.

SubsCache.subscribe('user', id1);
SubsCache.subscribe('user', id2);

In the older versions of this package, multiple cached subscriptions were possible.
I think it is related to the hash calculation (you only use the first param for it).

Was just wondering if you use a subscription cache for paging through documents using a skip, limit, and sort, for example, as you page through the documents, those documents will get retained and build up in minimongo on the client.

You'll then need to update your client code to paginate through them correctly. Where with just using regular pub/sub you only have the current page of documents on the client, so you code can just return the currently published set of documents (which is really the current page).

If you update your client code to pass skip, limit, and sort to a minimongo query, in order to retrieve the correct page of documents from all the cached documents, what happens when the cached subscriptions expire in the middle of all this?

Seems like that would throw a wrench into everything... like sand shifting underneath your minimongo code.

Hi @ccorcos,

We only recently started using this package, to replace SubsManager that's causing us some problems. But I just found out about the deprecation notice you added a few days ago. Could you share the reasons – is it because you don't plan to maintain it anymore or are there some serious issues with the approach of taken by this library?

Thanks.

When using subs-cache to manage a subscription that has a Counts.publish, after a subscription is stopped - sub.stop() - and then re-started (re-subscribing again), the published counts stop being pushed to the client via DDP... If it is not stopped and just re-subscribed (for example if it is subscribed within a autorun in a Template onCreate callback due to change on criteria), all works fine.

Any idea?

Hello,

This error occurs when i'm deleting an entity that has been subs-cached. I've seen that it already happened in #4 and #10.

Exception in queued task: Error: Can't set timers inside simulations
    at withoutInvocation (http://localhost:3000/packages/meteor.js?hash=ae8b8affa9680bf9720bd8f7fa112f13a62f71c3:463:13)
    at bindAndCatch (http://localhost:3000/packages/meteor.js?hash=ae8b8affa9680bf9720bd8f7fa112f13a62f71c3:471:33)
    at Object.setTimeout (http://localhost:3000/packages/meteor.js?hash=ae8b8affa9680bf9720bd8f7fa112f13a62f71c3:487:23)
    at Object.delayedStop (http://localhost:3000/packages/ccorcos_subs-cache.js?hash=42b5cad3111cb64c8824058a364c995113d9f827:218:44)
    at http://localhost:3000/packages/ccorcos_subs-cache.js?hash=42b5cad3111cb64c8824058a364c995113d9f827:209:30
    at http://localhost:3000/packages/tracker.js?hash=f525263111eb9d90f4ce1ad064f97aca4a6c1b07:302:31
    at Object.Tracker.nonreactive (http://localhost:3000/packages/tracker.js?hash=f525263111eb9d90f4ce1ad064f97aca4a6c1b07:631:12)
    at Tracker.Computation.invalidate (http://localhost:3000/packages/tracker.js?hash=f525263111eb9d90f4ce1ad064f97aca4a6c1b07:301:15)
    at Tracker.Computation.stop (http://localhost:3000/packages/tracker.js?hash=f525263111eb9d90f4ce1ad064f97aca4a6c1b07:320:10)
    at stopComputation (http://localhost:3000/packages/blaze.js?hash=ef41aed769a8945fc99ac4954e8c9ec157a88cea:1887:44) undefined
debug.js:43 Clock discrepancy detected. Attempting re-sync. undefined

The entity is beeing deleted as expected, but it appears to still be in the cache and the templates aren't refreshed as expected. I've found no workaround so far...

The subscriptions should be stopped when the cacheLimit is reached even if the expireAfter has not expired yet.

Without this it the cacheLimit is useless when the expireAfter is set to something other than -1 because the subscriptions keep pilling up indefinitely.

this question is related to this thread on the forums: https://forums.meteor.com/t/template-subscribe-and-subsmanager/2003

We're looking to add a subs manager for React native. Would this work as an npm package out the box for React native?

When providing an onReady callback to Meteor.subscribe, it will always be called, even if an identical subscription is already active. subsCache.subscribe does not behave in this way; if a subscription with the same arguments already exists, the callback is ignored.

For example

var l = function() { console.log("onReady"); };
var sc = new SubsCache({
  expireAter: 5,
  cacheLimit: 10
});

Meteor.subscribe("mysub", l); // "onReady"
Meteor.subscribe("mysub", l); // "onReady"

sc.subscribe("mysub", l); // "onReady"
sc.subscribe("mysub", l); // nothing, never

Is subscription determined to be active before being stopped on limit reach?

I was thinking about trying to determine if subscription is being active to adjust allReady(), and start caching by pages, as well as stopping the duplication of subscriptions when they have different params.
P.S.: by requiring that users pass subscriptions in the tracker.

This is not working, nothing shows up in the console when the onReady callback should be called. Suggestions?

const subs = new SubsCache({expireAter: 5, cacheLimit: 5});
const sub = subs.subscribe("videos", params);

sub.onReady(function() {
    console.log('hello');
}

The version in this package is 0.9.0 but has never been published to atmospher

Also, there package is trying to load src/subsCache.js but the filename is src/SubsCache.js

That plus the fact it's written in es5 and the package doesn't include ecmascript
I opened a PR #37 to fix it.

Hi guys,

there is a bug with handling constructor-parameters.

if I initiate via

export const globalSubscriptionManager = new SubsCache(
  {
    expireAfter: 11,  // Minutes to expire
    cacheLimit: -1,   // unlimited cache
    debug: Meteor.isDevelopment,
  },
)

then those parameters are not parsed correctly in the instance.

This works better in https://atmospherejs.com/blockrazor/subscache-c4 1.

I just switched over from subsManager, and this is the error message I'm seeing on the server:
There is no such publish handler named: undefined

Was working fine before the switch over. Any ideas?

I started using this package in my production app and I'm noticing the following doesn't always work:

subsCache.ready() - tells you if all subscriptions in the cache are ready

It will regularly not return true. However, I created my own global helper that loops and checks each individual cached subscription using the sub.ready() call and it works great:

Template.registerHelper('cachedTemplateSubscriptionsReady', function() {
  const subscriptions = Template.instance().subscriptions;
  if(subscriptions) {
    for(const subscription of subscriptions) {
      if(!subscription.ready())
        return false;
    }
  }
  return true;
});

I'll try to dig into the code myself but I wanted to report this here.

Hi,

After replacing some of the Meteor subscriptions to cached subscriptions some of them seem to have been overriding each other. (when one subscribes the former disappears)

I'm not sure when it happens or how to recreate this... or how to avoid it.

When making multiple subscriptions to the same point (I.e. 'post, 1', 'post, 2',[...]) how does the cache keep track and determine which subscription is which?

Looks like the package hasn't been published on Atmosphere for a while, is it on purpose?

https://atmospherejs.com/ccorcos/subs-cache