Mastering Web Application

Chapter 6

Let's consider a partial providing a screen for editing a user's data:

<div ng-controller="EditUserCtrl">

<h1>Edit user</h1>

</div>

We could modify it by removing the ng-controller directive as follows:

<div>

<h1>Edit user</h1>

</div>

Instead of that we can define the controller service in the route level as follows:

.when('/admin/users/:userid', {

templateUrl: 'tpls/users/edit.html'

controller: 'EditUserCtrl'})

By moving the controller to the route definition level, we've gained the possibility of
reusing the same controller for different partials and more importantly, reusing the
same partials with different controllers. This additional flexibility comes in handy in
several situations. A typical example would be a partial containing a form to edit an
item. Usually we want to have exactly the same markup for both adding a new item
and editing an existing item, but behavior for new items might be slightly different
as compared to the existing ones (for example, creating rather than updating when
persisting the item).

Avoiding UI flickering on route changes

While an application transitions between different screens, we usually need to
get and display markup for a new screen as well as fetch the corresponding data
(model). It turns out that there are two slightly different strategies that we can use to
render a new screen, which are as follows:

• Display new markup as soon as possible (even if corresponding data are
  not yet ready) and then repaint the UI upon arrival of the data from the
  back-end.


• Make sure that all the requests to the back-end are completed and the data
  are ready before displaying markup for a new route