Override Transition defaults in order to prevent false positives on page reloads

[alechenninger]

On transition, we can check if the "destination" view is already loaded in the desired context, and if so take some extra measures to prevent a false positive (that is, completing the wait before we've reloaded the view).

There are a few possibilities to do this. One of which could be to set a flag on the document in javascript that would be blown away once the new DOM is loaded for the next page. Another could be grabbing a reference to the "body" tag and waiting for it to be stale.

[alechenninger]

Either of those options might even be helpful as baseline for all transitions to prevent false positives.

[alechenninger]

One thing to note is that if people automating single page web apps are already using transition() where there is not technically a page reload, we have to be careful about either not breaking that behavior or making it an explicit breaking change that transition in the context of a browser means a normal, url-change page reload.

[alechenninger]

Different frameworks have different ways of keeping track, for instance angular's protractor watches some classes in the dom or something like that in order to prevent false positives on page reloads. So we could have other types of transitions like, AngularTransition, perhaps.

[alechenninger]

Starting looking into this a bit more yesterday. One challenge is that the transition event may be awaited after the transition has already started. Which means if we want to await for an element to be stale or something, we might not be finding it until it's already been reloaded, in which case it will never be stale. We could get a reference to a root element at creation of the transition event, which would work with the canonical usage of the pattern, but kind of changes the contract of using a transition event, so worth giving some pause to before implementing.