feat($on#event.preventDefault(promise)) optionally pass a promise into `preventDefault`

[rynz]

Currently we can listen and cancel events such as $locationChangeStart with the event object's preventDefault method.

What does everyone think of this proposed idea:
preventDefault - {function|Promise}: calling preventDefault sets defaultPrevented flag to true. Optionally pass a promise, when resolved continues the event. When rejected sets defaultPrevented flag to true.
defaultPrevented - {boolean}: true if preventDefault was called or it's promise rejected.

With this being implemented in Angular Core it would mean issues like angular-ui/ui-router#591 could be handled in a more decoupled way.

For example:

var $off = $rootScope.$on('$locationChangeStart', function(event) {
  // Some user service that checks if the user is logged
  // in to our system and sets up the appropriate services
  // for our application.
  var httpUserPromise = $http.get('/auth/user').catch(function() {
    // User is not logged in, do our special handling just like we
    // would if we were calling `preventDefault` sychronously.
  });
  event.preventDefault(httpUserPromise);
  // Deregister listener so it is only called on
  // first `$locationChangeStart` event.
  $off();
});

This would give a wealth of deferred functionality for handling events allowing uses to asynchronously request application configuration in event listeners and allowing Angular to handle the event normally when resolved and in a custom manner when rejected.

[tbosch]

Well, the problem is that while the promise is not resolved the user could already navigate to another url.
Does not sound right...

Do you have more usecases for this?

[rynz]

Hmm that is true, could the promise not be cancelled/rejected though if that were the case?

Most use cases are for $http that I can think of - I'm not quite sure where a better place would be to perform this kind of bootstrap / deferred loading.

Sure, another uses case is with 3rd party angular libraries.

For example ui-router uses $locationChangeSuccess as it's entry point for state management.
With this in mind you could intercept the earlier event $locationChangeStart, check if a particular state does not exist for the location and use $http to lazy load the appropriate data / javascript / state configuration. Once resolved the $locationChangeStart continues seamlessly for ui-router to use.

It allows for some very nice decoupling of deferred logic around angular, your own and third party library events.

[alonbardavid]

As far as I can tell it's not currently possible to defer the first locationChangeStart before something happens.
if you do:

var $off = $rootScope.$on('$locationChangeStart', function(event,newUrl,oldUrl) {
   event.preventDefault();
  doSomethingAsync.then(function(){
    $location.url(getPath(newUrl));
    $off();
  })
});

in the case where newUrl and oldUrl are the same (as in the original initial request) the the later $location.url(path) will not do anything (such as calling the required $locationChangeSuccess) since it's not registered as a change of url anymore.

this feature would allow us to defer the initial request, that we currently can't do without either:

• copying internal angular implementation (calling $locationChangeSuccess ourselves)
• using a routing service that uses $locationChangeSuccess, such as ngRoute resolve or ui-router's sync() method.

[rynz]

When I added the sync() method to ui-router it allowed us to achieve a really clean authentication layer. The only pitfall is we must use the $injector to defer $urlRouter from being created via DI otherwise it would already be initialized and we could not defer the event.

Eg:

// Handle user checking on application start.
app.run(['$rootScope', '$injector', 'auth', function($rootScope, $injector, auth) {
  var $off = $rootScope.$on('$locationChangeSuccess', function(e) {
    e.preventDefault();
    // Inject $urlRouter so it binds to $locationChangeSuccess
    // after this event listener is triggered. Order matters!
    auth.user().then(function() {
      $injector.get('$urlRouter').sync();
      $off();
    });
  });
}]);

We can also use this mechanism to bootstrap configuration of the application, additional routes etc. I'm not sure of any other better way to do this in angular other than using ng-if to load in the main app once all your promises resolve.

[andrezero]

Hi

I have another use case for this and I'm quite desperately looking for a workaround.

I was planning to implement a route interceptor service that different controllers can register. The goal is to prevent users from navigating if they have pending changes on one or more widgets in the page.

But not only I want to prevent navigation from happening, I want to present a "SAVE NOW" or "DISCARD" dialog and then proceed with the route change when the dialog+save promise is resolved. Or cancel it if the user decides to stay in the current page or if save fails.

Using route resolves, I end up with the wrong URL in the address bar. It's a documented issue and although there are some pointers out there, I wasn't able to return the address bar to the actual state without reloading the page and forcing the user to loose all the changes.

Using locationChangeStart looked promise, because I am able to prevent the route change with preventDefault() but...

1. I need to keep the url around to track whether I should event.preventDefault() again or allow it to change, as in.. the user as pressed save and all is saved, we don't want to cancel this time
2. I have to prevent navigation to that same url, using a blocking modal dialog ... still the user can press back button .. twice, and there we go...
3. because of the second call to location.path() I end up with a messed up history. Whether I use .replace() or not, I can go back, but not forward.
4. there's some address bar flickering go in on all the time

Here's my 2:30AM "I give up" iteration. As in, this is never gonna work :-(

Any ideas on how to achieve this in a clean way? Any plans for making these events accept an asynchronous preventDefault(); os something similar?

Thank you for you time.

var nextUrl;
$rootScope.$on('$locationChangeStart', function (event, next, current) {
    if ($route.current) {
        if (nextUrl === next) {
            nextUrl = null;
        }
        else {
            event.preventDefault();
            beforeRouteChange().then(function () {
                nextUrl = next;
                parser.href = next;
                $location.path(parser.pathname);
                $location.search(parser.search.replace(/^\?/, ''));
                $location.hash(parser.hash.replace(/^#/, ''));
                $location.replace();
            });
        }
    }
});

[caitp]

this means either:

• location events should always wait until the next turn before deciding how to treat the event, because it might be a promise or might not be (maybe, but this is a breaking change)
• location events should sometimes be treated synchronously, and sometimes not, if preventDefault is called with a then-able (bad! terrible design here!)

I'm not too keen on either of these scenarios, but if people are satisfied that this would be a valid breaking change that should be made, then maybe a fix should land

[andrezero]

Hi! Thank you for your answer.

I'm pretty sure a breaking change is better than a terrible design, but I'm not too familiar with angular source. I usually try to, but mos of the internals just transcend me :-D

Just another thought that that I had ... instead of the whole mess with async events.

The key idea here is here is to have an event that triggers "before" window.href and history are ever touched. It might be naif but looks like the ideal behaviour.

$rootScope.$on('$locationChangeStart', function (event, next, current) {
    if (asynchronous condition) {
        event.preventDefault();
        $location.freeze(next);
        asyncCode.then($location.commit, $location.rollback);
    }
});

Optimal behaviour would be:

• commit and rollback would be ignored if no change "freezed"
• any calls to location while a freeze state exists would be ignored (including browser back/fwd where supported)
• commit would navigate to freezed "next" without triggering locationChangeStart
• rollback would clear the freezed status
• browser back/forward button (where supported) would transparently trigger this behaviour with a pristine browser history (that probably means modifying browser history and preserving the intent to apply at commit time)
• any other interceptable location change (can't think of any now :-/)

I obviously don't know enough about angular of even the history api.

But I'll learn it if I need it because I'm determined to implement this valuable feature in two rather complex projects I'm working on:

• prevent user from loosing changes
• give user the option, act upon it
• seamlessly proceed with navigation whether it was originally triggered by navigation, forward or back!

I'll humbly retreat to my cave now. Thank you for your time again.

[nlwillia]

This topic has been on my mind as well. Event listeners are conventionally synchronous. If they're going to veto or modify the event, they must do so synchronously. Everything about the dispatch model is synchronous from $broadcast and $emit to preventDefault. But there are scenarios where I don't want the event to be considered "completed" until something asynchronous has occurred or I won't know whether the event should be prevented until an asynchronous call has returned. Both come up frequently in UI routing.

In ui-router, you can specify asynchronous resolves per state, but if you're doing something more dynamic based on the state change events, you're on your own. For asynchronous veto (ex: waiting on an http call to save your work or a modal "are you sure" dialog), the pattern I've followed is to eagerly veto, run the async task and then if it succeeded, deregister my veto listener and re-trigger the event, but this becomes unrealistic to manage if there are multiple listeners that may veto. Such a scenario is less common, but it boils down to a 2-phase commit problem, and that's complexity that application code should be insulated from.

Giving event listeners a way to return asynchronously would mean that $broadcast and $emit would have to return promises which would be a fairly significant breaking change. Separate $broadcastAsync and $emitAsync would work for the triggering side of the API, but then you'd have event listeners that would work or not depending on how the event was dispatched which would be awkward. Maybe that's the only practical way forward. Or, maybe asynchronous event dispatch isn't as useful as it sounds like it would be. But given how prevalent promises are in Angular and ui-router, it does make you wonder if the core event mechanism wouldn't be improved by the feature.