title: Apply loading spinner during ui-router resolve
body: <p><code>resolve</code> property of <code>$routeProvider</code> allows to execute some jobs BEFORE corresponding view is rendered. </p>
  
  <p>What if I want to display a spinner while those jobs are executed in order to increase user experience?<br>
  Indeed, otherwise the user would feel the application has been blocked since no view elements were displayed for some milliseconds > 600 for instance.</p>
  
  <p>Of course, there was the way to define a global <code>div</code> element <strong>out of the current view</strong> to display in order to display the spinner thanks to the <code>$scope.$rootChangeStart</code> function.<br>
  <strong>But I don't want to hide the whole page with just a poor spinner in the middle.</strong><br>
  I want some pages of my webapp differ regarding the way the loading is displayed.</p>
  
  <p>I came across <a href="https://github.com/angular-ui/ui-router/issues/456">this interesting post</a> containing the exact issue I described above:</p>
  
  <blockquote>
    <p>That approach results in a horrible UI experience. The user clicks on
    a button to refresh a list or something, and the entire screen gets
    blanketed in a generic spinner because the library has no way of
    showing a spinner just for the view(s) that are actually affected by
    the state change. No thanks.</p>
    
    <p>In any case, after I filed this issue, I realised that the "resolve"
    feature is an anti-pattern. It waits for all the promises to resolve
    then animates the state change. This is completely wrong - you want
    your transition animations between states to run parallel to your data
    loads, so that the latter can be covered up by the former.</p>
    
    <p>For example, imagine your have a list of items, and clicking on one of
    them hides the list and shows the item's details in a different view.
    If we have an async load for the item details that takes, on average,
    400ms, then we can cover up the load almost entirely in most cases by
    having a 300ms "leave" animation on the list view, and a 300ms "enter"
    animation on the item details view. That way we provide a slicker feel
    to the UI and can avoid showing a spinner at all in most cases.</p>
    
    <p>However, this requires that we initiate the async load and the state
    change animation at the same moment. If we use "resolve", then the
    entire async animation happens before the animation starts. The user
    clicks, sees a spinner, then sees the transition animation. The whole
    state change will take ~1000ms, which is too slow.</p>
    
    <p>"Resolve" could be a useful way to cache dependencies between
    different views if it had the option not to wait on promises, but the
    current behaviour, of always resolving them before the state change
    starts makes it almost useless, IMO. It should be avoided for any
    dependencies that involve async loads.</p>
  </blockquote>
  
  <p>Should I really stop using <code>resolve</code> to load some data and rather start loading them in the corresponding controller directly? So that I can update the corresponding view as long as the job is executed and in the place I want in the view, not globally.</p>