uzikilon / backbone-poller Goto Github PK

Hey, It would be nice to be able to pass options into the fetch command when polling a collection, such as {add:true} so that on each poll the collection is not reset, and any new models are just added to the existing collection.

In my case throwing an error if the poller has already been activated on a model is too strict, so i've removed it in my local copy. Perhaps change this to just console.warn the user and return?

I'm having issue with the "start()" which is suppose to stop() and start() so that the new options can be updated as you suggested.

I simplified my code to run some experiment and here is what I did... Essentially, I start the poller and then after 10 sec re-start the poller (suppose to the change the time out, but just keep it the same for now).... do the restart twice...

var Polling = Polling || {};

Polling.model = new Backbone.Model();
Polling.model.url =  'url.example.com';

Polling.poller = PollingManager.getPoller(Polling.model, {delay: 10000, fetch: function () {console.log('pre-fetch @' +  new Date());} }).start();

Polling.restart_count = 0;

Polling.restart_poller = function () {
    Polling.restart_count ++;
    console.log ("Restart the poller: count = " + Polling.restart_count );

    Polling.poller = PollingManager.getPoller(Polling.model, {delay: 10000}).start();
    if (Polling.restart_count >= 2) {
        console.log ("No more restart the poller");
        window.clearTimeout(Polling.timer  );
    }   
};

Polling.timer  = window.setInterval( 'Polling.restart_poller()', 10000);

The expected behavior is that after each re-start, the poller should just continue to poll at every 10 sec.. since I did not change anything....
But the result is different, after the 1st re-start, I start to see that there are two back-2-back pollings every 10 sec
After the 2nd re-start, there are three back-to-back polls for every 10 sec..

Seems that the original scheduled pollings are not cancelled but just keep adding to it...

Here is what I see from the console log

pre-fetch @Wed May 16 2012 23:51:58 GMT-0400 (Eastern Daylight Time)

<< These two lines I can understand since the original poll finished and new one starts also>>>
Restart the poller: count = 1
pre-fetch @Wed May 16 2012 23:52:08 GMT-0400 (Eastern Daylight Time)
pre-fetch @Wed May 16 2012 23:52:09 GMT-0400 (Eastern Daylight Time)

<< We should see only two lines; but there are three!!>>>
Restart the poller: count = 2
pre-fetch @Wed May 16 2012 23:52:18 GMT-0400 (Eastern Daylight Time)
No more restart the poller
pre-fetch @Wed May 16 2012 23:52:18 GMT-0400 (Eastern Daylight Time)
pre-fetch @Wed May 16 2012 23:52:19 GMT-0400 (Eastern Daylight Time)

<< We should see only one poll but there are three!!>>>
pre-fetch @Wed May 16 2012 23:52:28 GMT-0400 (Eastern Daylight Time)
pre-fetch @Wed May 16 2012 23:52:29 GMT-0400 (Eastern Daylight Time)
pre-fetch @Wed May 16 2012 23:52:29 GMT-0400 (Eastern Daylight Time)

<< We should see only one poll but there are three!!>>>
pre-fetch @Wed May 16 2012 23:52:39 GMT-0400 (Eastern Daylight Time)
pre-fetch @Wed May 16 2012 23:52:39 GMT-0400 (Eastern Daylight Time)
pre-fetch @Wed May 16 2012 23:52:39 GMT-0400 (Eastern Daylight Time)

Hey uzi, I think I preferred it before when I could create an instance of a poller at initialization but start it later on. Something like

at initialization:

poller = PollingManager.create(model_or_collection, options)

and later

 unless poller.active()
    poller.start()

when i start a poller with
plr = Backbone.Poller.get(my_list_view.collection, { update:true }).start();
and listen to all the events, I see that it fires resets, and doesn't fire change events when db is updated, in contrast to manually polling (with setTimeout) my_list_view.collection.fetch({ update:true }), which fires change events (and doesn't fire resets) as expected.

Hi,

First thank you for this nice plugin!

I'm beginning to use it on my project. I just poll a single model in basic use case, and I add a strange issue: the complete callback method was getting called while the polling was continuing, and when finally stopping it was called twice instead of once.

I investigated just a little and found there was a jQuery complete event called on the model when fetched which was incorrectly triggering the poller's complete callback.

A simple way of correcting the issue was to prefix every polling event by polling, so I have now pollingComplete triggered instead of complete.

I can't npm install this module (for use in a commonjs / browserify app) because it attempts to run "bower install" as part of the module postinstall script.

Looks like it was copy/pasted from 0.3.

Hello. I'm using bower for integrate poller into my project. But I can't lock version 'cause this repo haven't any tag. Can you add some tags please?

Hi,

I'm scratching my head as to whether this is an appropriate solution for me. I need to periodically re-fetch a number of collections at a given interval and at the same time (or sequentially) - however won't the number of setTimeout calls increase with the more models/collections I introduce to poller? If I had 20+ items polling wouldn't it become difficult to keep them all polling in sequence? I can also imagine this having a performance hit.

Hope you can address some of these questions

Hi @uzikilon, thanks for making this project!

I've been building a project using lodash instead of underscore and I think I've found an issue where _.each is called in set (https://github.com/uzikilon/backbone-poller/blob/master/backbone.poller.js#L98) using this - which doesn't seem to be supported by lodash.

This means whenever Poller.get(model) is called, an error is raised.

I'm just working on a feature that provides auto-save capabilities and it'd be really nice to use backbone-poller to achieve this.

My thinking is the API could be:

this.poller = Poller.get(this.model, {method: 'save'});

With method defaulting to fetch.

In version 0.2.5 this problem appears but in 0.2.2 it isn't.
I tested it with normal and minified files in Mozilla Firefox and Google Chrome.
The problem happened with the next code (it's in coffeescript sorry):

applicationCollection = new Cockpit.Collections.Applications()
poller = new Backbone.Poller.get(applicationCollection, delay: 3000)
counter = 0
kill = (po) ->
  console.log('killing')
  # Also Backbone.Poller.reset() doesn't work
  po.stop()
  console.log('should be killed')

poller.on('success', (model)->
  console.log('success get polling')
  counter = counter + 1
  if counter  == 2
    kill(this)
)

On user activity, I used to do this.

if(this.poller){
this.poller.stop()
} 
this.poller.start()

so that poller would restart. I have a 30 sec delay in poller which will delay the next calls.

Recently I changed it to..

if(this.poller){
this.poller.destroy()
}
this.poller.start()

Now I observed that, The network call does not happen immediately, it will just happen after 30 sec and every 30 sec there after. Somehow destroy() is not stopping the poller when start is called immediately after that. Is it some race condition triggering this behaviour.?

For now I have changed it back to stop() and that fixes the issue.

Thinking to have settings to control delay.. and it can be user set value..
Seems delay can only be set during initialization??

I could use an option to prevent the poller for stopping after a fail to avoid manually restarting the poller on error.

On overload some back-end / server can time-out or through 500 but respond well when hitting again.

• Always use the latest of the dependency libraries, to make sure the project doesn't break when new libraries come out.
• Figure out if there's a way to ask Travis CI to run periodically.

When calling _.defer(run(this)) in start, the input function evaluates to undefined inside _.defer

Would be nice to do another check for completion in the success callback, that way you don't have to wait another x amount of seconds for the Poller to realise its complete.

In testing, I have noticed that the poller 'on error' only accepts once parameter (the model). Is it possible to get the original response object, so a reason for the failed fetch can be determined?

Something like:

         clusterHealthPoller.on('error', function (healthModel, reponse) {
                        var status = reponse.status;

...

I have a case where the poller can be half way through polling a collection and the user switches views, I explicitly call poller.stop but the complete callback is fired. I don't think this is semantically correct as the polling never completed, but was interrupted.

Right now it stops the poller completely, but I think it would be more convenient to continue to validate the condition on timer and resume polling if the condition became true again.

Have a need to do some tasks every time right before the poller start polling
Can you add the beforeStart callback?

Thanks