Add offline tracker capability using onerror callback and localStorage

[rcs]

I'd like to add offline support for the tracker.

I think this can be added with an onerror callback on the image load. Would it make sense to push this through the a "setBeaconError" for the tracker, or would you prefer a different approach?

// in initialization
_snaq.push(['setBeaconError', function() { ... } ]);

...

// Added to tracker
setBeaconError: function( onError ) {
  configBeaconError = onError;
}

..
// In getImage.
if( configBeaconError ) {
  img.onerror = configBeaconError;
}

[alexanderdean]

Hey Ryan Sorensen (@rcs) ! That looks neat, thanks for raising... Out of interest, what would you do with the offline status? If the browser is offline, what would you be putting in function() { ... }.

I ask because I'm interested if there's some sort of generalizable offline option which would be useful for all Snowplow JS Tracker users...

[rcs]

Thinking about pushing it out to localStorage if it's supported, then trying again later.

Probably fairly generalizable. Would be even better with batch support in the collectors.

[alexanderdean]

Pushing to localStorage makes sense - with your suggested approach, how would you access the request payload for storing in localStorage?

I'm wondering if it might be better to formally try {} catch {} the getImage() and write the request to local storage if unsuccessful...

[rcs]

The onerror callback should have access to this.src, which is the image's src attribute we're setting, and can be pushed into a retry queue.

Unfortunately, I don't think we can do a try {} catch {} here, since the failure won't raise an error, and the image failure doesn't hit until the next tick -- meaning we've lost the call stack.

[rcs]

Thinking about this a bit more.. We could absolutely stringify request into localStorage for the next run, but that does mean adding the rehydration of those JSON objects back into string builders. I'm not sure if there's much gain from doing that, since I think we're turning it back into a url anyway?

[alexanderdean]

Probably easiest is just to put the finalized querystrings (?e=pv&...) into localStorage? The rest of the collector URL could be rebuilt very easily when it's time to try resending.

[alexanderdean]

On your prior comment above - sounds good re. this.src and understand the issue with try {} catch {}, thanks for clarifying.

I would say, rather than make this a general-purpose capability with setBeaconError, it's more interesting to flesh out a full save-to-localStorage-on-error option.

Recovering from localStorage and re-sending could always become "phase 2" if the job becomes too big...

[alexanderdean]

This is tracked for release as #24, so closing this ticket.