Request error blocks UI

[soundstep]

I'll just keep you posted with things I had to changed if that ok, so you can judge what would be the best course of actions.

Also because I'm not how everything was meant to be used.

If a request fails in my app, a transaction error in throw in the $view.beginUpdate nethod.

https://github.com/dotJEM/angular-routing/blob/master/src/view.ts#L416

This was just blocking the UI completely, errors will be handled but I'm not too comfortable having an error that can stop the user doing what he wants. SO I just commented that errors.

Please ignore if that's not relevant, I had to quickly solve the problem.

[jeme]

Could you describe that a bit further?... or provide an example... what sort of request failure are we talking about specifically... (jsfiddle would be much appreciated).

Because if you not calling $view.beginUpdate anywhere, this sounds like a bug... If you do call it, you may be calling it in a wrong context. If that situates a valid scenario I think the approach would be to allow an alternative handling through configuration (onError handlers although I am overall against those).

[soundstep]

The request failure was an $http.get to our own API on a remote server, a CORS error to be exact (we were messing with json and jsonp). Just a normal error.

Here is what happened:

• click on a link
• location changed to /mypage
• a mypage state execute the resolve property
• data is pulled from the API ---> CORS error at that point (or probably any kind of error)

So the controller of /mypage is not instantiated as the resolve failed.

Now clicking on another link, that does:

$location.path('/anotherpage');

Would throw that transaction error I was talking about.

[jeme]

In that case it seems to be a bug.

Can you say where the $http.get is called, (in a resolve, controller or transition to see where there is some missing error handling)... Because it seems like the previous view transaction does not get canceled as it should.

I will look into it when I can, but I am a bit busy during the weekend so won't have time to start looking at it before next week.

[soundstep]

No worries, the $http.get was a service used in the resolve property of the state.

$stateProvider
    .state('visualisation', {
        route: '/explore/:entity/:id',
        views: {
        'main': {
                sticky: true,
                template: 'visualisation/visualisation.html',
                controller: 'VisualisationController'
         }
    },
    resolve: {
        visData:['EntityService', 'ResolveService', function (EntityService, ResolveService) {
            return ResolveService.resolve('visualisation', EntityService.get($route.current.params.entity, $route.current.params.id ))
                 .success(function(result) {
                     // storing something
                 });
             }]
         }
    });

The Resolve service is what I have been talking about there: #54

But I'm pretty it would have been the same with just the service call in the resolve.

Hope that help.

[jeme]

Demonstration of error:

http://plnkr.co/edit/rXIU7ZdlGT1GENdjS4KW

[soundstep]

Ah yes, that's the one!

[jeme]

There is still a long way to go on resolve, but the view transaction should now be canceled on resolve errors as was the expected behavior.