Events after document.open are not captured

[mstn]

If I bind an event fired after dom replacement (lines 333-336) before dom replacement, for example

   document.addEventListener('MeteorRiderReplaceComplete', function(){
        alert('COMPLETE');
   }, false);

   and then MeteorRider.init

binding is lost and, as a consequence, the event cannot be captured. I think the reason is that document.open clears the existing document as well as its listeners.

[mstn]

I patched this problem creating a sort of event bus object with a fake dom element and replacing document with this.events in triggerEvent.

 var MeteorRider = {
     events: document.createElement('div'),
     ...

Perhaps a small pub/sub library is better.

[zeroasterisk]

Well hell -- you're right, and that certainly makes sense....

The nested events as a div element is tricky as hell, I never would've thought of that...

a pub/sub might be better, but I'd like to keep things as simple and dependency free as possible... though we could just embed the pub/sub system into the MeteorRider class/file.

or we could be lazy and just make it "re-apply" all events to the new document every time it re-created it...(?)

[mstn]

I thought about the last one. However, I do not know if it is possible to get all the listeners attached to a dom element. Perhaps the best option is a minimal home-made pub-sub.

[zeroasterisk]

so how about a MeteorRider.createEvent() which did a "real time" create/attach to the current document AND stored in a MeteorRider.events array, and on DOM re-write it re-applied all of those listeners (before it triggered it's "done" events)?

[mstn]

It could work. Just wondering why events should be attached to "document". We could listen to events triggered by MeteorRider. In other words, MeteorRider itself could implement a sort of observe pattern. Of course, I am not sure this is the "right" thing to do.

[zeroasterisk]

Right - well MeteorRider could become an "exchange" between Cordova and Meteor - that makes some sense and what @raix did with https://github.com/SpaceCapsule/Meteor-cordova

But...

I think one of the main benefits of this is having the document already exist (sort of)... and you should be able to access it and utilize it directly...

So...

1. Cordova loads
2. MeteorRider hijacks the DOM
3. Meteor loads

after 2, or maybe 3, I really kinda want MeteorRider to disappear...

the only events MeteorRider cares about are during 2 (and maybe 3 if we get fancy).

so, IMO, we just need to expose a way for Cordova events from 1 to be re-loaded onto the document after 2.

[mstn]

I understand. It seems sensible to me. Probably, now I understand why in replaceDoneTriggerEvents you called events without MeteorRider- prefix as in other parts of the code.

Just to play the role of the Devil's advocate, MeteorRiderReplaceComplete event is an event tightly bound to MeteorRider. It makes sense only in the context of MeteorRider. It is not a cordova event or a document event. As a user of MeteorRider, I'd like to have some control on the process underlying MeteorRider (e.g. redirect to fallback page when something goes wrong). Hence, I do not want to be fully agnostic of MeteorRider things. In this case, maybe it could make sense to have a listener specific for MeteorRider.

[zeroasterisk]

You're right on top of things - that's the basic idea I was going for... a set of custom events where you could setup your own callbacks in the case of a failure, etc... I was hooking them on the document thinking it was the simplest, but obviously not if they are being cleared/re-written.

Open to suggestions, pull requests, if you have an idea on improving...

As of now, it is a "feature" I was playing with, currently undocumented.

[mstn]

I am going to play a bit with MeteorRider so that I can understand better what are my needs. Then I'll create a pull requests/proposal.