The $routeParams service is injected in the controller. It allows us to retrieve the current set of route parameters. Since we had specified :buildingIndex as a route parameter (while setting up our routes), we retrieve it using $routeParams.buildingIndex. The buildingSvc service is also injected and the index (of the building) is passed to this service, which returns a synchronized object to us. Finally, we bind the returned synchronized object to $scope using the $bindTo method. The first argument to this method is $scope and the second is the name of the variable which we want to appear on $scope. Since the value of the second argument here is building, $scope.building is available to the view(s):

<div class="panel panel-default">
<div class="panel-heading">
<h3 class="panel-title">Update building</h3>
<div class="panel-body">
<div class="form-group">
<label for="number">Building Number</label>
<input type="number" class="form-control" id="number"
  ng-model="building.buildingNumber" placeholder="Enter building number">
<div class="form-group">
<label for="name">Building Name</label>
<input type="text" class="form-control" id="name"
  ng-model="building.buildingName" placeholder="Enter building name">


When you click on any of the building number links on the existing buildings page, you’ll see the data for that building reflected in the two input textboxes on the update building page. Also, notice that there is no Submit button for this form and we are not even calling $save() anywhere. Now these textboxes are bound directly to Firebase and sync their changes with Firebase automatically. So, if you make any changes to the data, that data will automatically be saved to Firebase.


Although three-way data bindings are extremely convenient, we should be careful while using these with deeply-nested data structures. For performance reasons, their use should be limited to synchronizing key-value pairs which don’t get changed by too many users.