3

I recently posted this question and figured out the direct solution (that being, I was able to cancel a promise/request when the route changed). However, I'm encountering another, related problem that I think belongs in a separate question so here it goes:

I'm able to abort my promise when the route changes just fine (as you can see from the question I linked). However, for some strange reason, any other requests on the other route are delayed when resolving. See my dev tools screenshot below.

Here's the scenario: I load route A, which makes the call to /api/categories and you can see it takes 30ms which is normal. Then I navigate to route B, then before it's done loading I return to route A. When I return, the call to /api/categorySites/1 is cancelled, and you can see when that happens as the gray bar ends. This is done by aborting the promise. However, back on route A again, the call to /api/categories doesn't resolve until that gray dot appears again on the request that was cancelled. That second call to /api/categories shouldn't take 2.23s, it should be closer to 30ms.

Dev tools

What's going on here? I would think the second Route A request would be just as fast as before. I need to get this to work faster. My code is in this question. Let me know if you think I should include it again here. It's hard for me to imagine this isn't a common problem too...

Community
  • 1
  • 1
Joao
  • 2,696
  • 2
  • 25
  • 35
  • Hmmm... did you ever figure this out? I'm running into the same. – Brian Oct 30 '14 at 19:59
  • I couldn't find a way. You'd think this was a more-common issue. What I did instead was improve my back-end processing speed by using caching so that the script didn't take so long so it was less noticeable to the front-end user. Of course that's not ideal and didn't really solve the problem. If you find an answer, please let me know! – Joao Oct 30 '14 at 20:06
  • 3
    When you're trying to make a request #6 changing route doesn't cancel the request but cancels promise. After changing route you make request #7 which calls the server and I suppose it can serve only one request simultaneously so you see that gap. What's in the back end? – kuzzmi Oct 31 '14 at 10:30

1 Answers1

1

This is an older post but I did look into this and this sounds like eager vs. lazy asynch transition that I read about in Emberjs documentation recently. On your routes (and subsequent aborts) fulfills the promise (completes), moves along to your re-route request.

I believe this can be improved with a state controller.

There is an Angularjs ui-router state controller that might be of use.

Here are example examples.

Angularjs routing documentation (for posterity).

So this is about $routeProvider (Angularjs default) enhanced by $stateProvider (ui-router) to expedite aborted routes.

Hope this is helpful (roughly 312 days later).

Frank Tudor
  • 4,226
  • 2
  • 23
  • 43