Auth.$bindTo implementation.

[jamestalmage]

Just an idea, but it seems like it would be helpful to bind authentication state to scope.
This mimics the $bindTo() method used for data binding.

I haven't tested it at all, submitted solely for your consideration.

[coveralls]

Coverage increased (+0.05%) when pulling 4db2139 on jamestalmage:auth-bindto into 6ed1fc1 on firebase:master.

[coveralls]

Coverage increased (+0.05%) when pulling ef23918 on jamestalmage:auth-bindto into 6ed1fc1 on firebase:master.

[coveralls]

Coverage increased (+0.05%) when pulling 092da01 on jamestalmage:auth-bindto into 6ed1fc1 on firebase:master.

[jamestalmage]

I added an example for how I envision the $bindTo function being used, and an associated build step.
It seems you guys are keeping examples elsewhere, but for right now, it does server as a sort of manual test. (It seems the old manual tests are broken?).

grunt example:auth

[coveralls]

Coverage increased (+0.07%) when pulling 9b3eb19 on jamestalmage:auth-bindto into 6ed1fc1 on firebase:master.

[coveralls]

Coverage increased (+0.07%) when pulling 9b3eb19 on jamestalmage:auth-bindto into 6ed1fc1 on firebase:master.

[coveralls]

Coverage increased (+0.07%) when pulling 0403260 on jamestalmage:auth-bindto into 6ed1fc1 on firebase:master.

[jwngr]

Prior to the 0.9.0 release, we provided an auth variable which we kept up-to-date with the current authentication state. I pushed to remove this in 0.9.0 since we now have the synchronous $getAuth() method. I do see the benefit of what you are doing here, but I just don't know if it provides anything you can't already do by calling $getAuth(). I also think if we re-introduce this kind of thing back in, it should just be as an auth variable like it used to be instead of having to register it yourself via $bindTo() (although I do like how you made the corollary there!).

@katowulf - what are your thoughts here?

[katowulf]

I'd prefer to see this as a service and not part of the core. I think both of you have made great points here and in our technical discussions and I still agree with our decision to take this out.

[jamestalmage]

The advantage of $bindTo() over $getAuth() or even an auth variable is that $bindTo() will automatically schedule a $digest cycle whenever login status changes. Users could do $watch(auth.getAuth(), function(){....}), but that doesn't handle triggering a $digest.

Users could certainly implement their own version of this pretty easily.

ref.onAuth(function(authData){
  scope.$apply(function(){
    scope.auth = authData
  });
});

The potential downfall there however, is that the Firebase reference is long lived and is now holding a reference to scope, so that scope can't be garbage collected. You could see how this could get messy inside a paginated ng-repeat. Of course, there are easy ways around that, but it's now complicated enough that it seems like something we should just solve for the users (especially since it is so easy to do so).

I'm curious why you argued to remove the auth variable. Maybe there is a good argument against what I am trying here that I'm just not understanding.

[katowulf]

Didn't realize that $onAuth() isn't triggering a digest. That we should definitely fix, which should make the rest of this much simpler. The reason auth was decided against is that it was essentially creating a global variable and all the baggage that comes with that (additionally there was no way to tell if it changed unless one $watched it, which you've already noted the issues with).

So essentially, $onAuth() should work in a real-time, event-driven manner, vs the old auth variable's essentially static behavior.

[jamestalmage]

Here is the use case I am trying to enable.

Controller:

ref.$bindTo($scope,'authData');

HTML:

<button ... ng-hide="authData.provider=='twitter'">Twitter</button>

<!-- or if you've implemented some additional info in your custom auth -->
<div ng-repeat="message in messages">
  <span>{{message.contents}}</span> 
  <button ng-show="authData.isModerator">Moderate this post...</button>
</div> 

[al-the-x]

The current implementation also doesn't play nice with the controllerAs syntax, either. The $onAuth method really should run the digest loop if not running already.

[katowulf]

@al-the-x please submit a new issue for that; will get it added; has nothing to do with Auth.$bindTo and won't get fixed here (as evidenced by the fact that this is the second comment added to this thread on that topic).

[jwngr]

Lots of good stuff in this thread. @katowulf went ahead updated $onAuth() to fire a digest loop so that issue is resolved. As for $bindTo() I think @katowulf and I are in agreement that this is not really needed and don't think the benefits outweigh the costs. With $onAuth() running a digest loop now, this should be super easy and natural for people to do anyway.

Closing this PR.

[al-the-x]

Great job!