Need support to unwatch when required about angularfire HOT 7 CLOSED

You should probably be doing this by simply destroying the scope on which
you have created the binding.

On 12 April 2013 17:30, Alexandre Bourget [email protected] wrote:

I bind a "$scope.data" to angularFire, using the normal method, inside a
Controller.

From that point on, any change to data will get reflected to a certain
location in Firebase.

At some point, I have a select box to switch profile, so I replace datawith a "new" profile. I would like to be able to unwatch the previous one,
because I'm now changing the location
of the data in Firebase (to a different profile, thus a different URL).

Right now, if I call angularFire() again, with $scope and data, it'll add
a second set of watches, and write to BOTH locations.. which becomes
increasingly odd :)

Also, right now if I try to remove or replace my data element, it deletes
on the Firebase side.. which isn't very nice once I'm done editing.

To attempt to fix this, I added a way to remove watches by tweaking the
call to $watch this way:

var unwatch = $scope.$watch(name, function() {
if (self._initial) {
self._initial = false;
return;
}
var val = JSON.parse(angular.toJson($scope[name]));
if (angular.equals(val, self._remoteValue)) {
return;
}
self.fRef.set(val);
}, true);
$scope['$ngFireUnwatch' + name] = unwatch;

First and last lines are important here.

So I manage to be able to remove the watches from my code, before calling
angularFire again.. and it works the first or second time I switch.. but
then it completely deletes my objects from Firebase.

How could we solve this elegantly ?

thanks for your great work

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13
.

from angularfire.

But I get another kind of problem.. it's that the fRef inside the angularFire keeps those fRef.on('value') bound.. and that's what's causing problems afterwards..

It seems that Firebase is kind of keeping a cache of those URLs we're passing through.. so keeps the hooks up if you come back and call angularFire() another time with the same URL..

So I kind of fixed it with:

$scope['$ngFireUnwatch_' + name] = function() {
  self._fRef.off('value');
  unwatch();
}

otherwise, it was deleting my things.

I thought of using the $scope.. but then my controller,s scope has other uses.. and I can't clean it up just to trigger one mechanism. And also.. I think the problem would persist, because it goes inside Firebase.. and its caching system (didn't look there though).

from angularfire.

AngularFire should be listening to the $destroy event on the scope to which
it is associated to do the unbinding.
If you are needing to bind and unbind values then I would, personally be
creating a new scope for this. This is what inherited scopes are for.
Just have another controller within the controller that you are currently
using.
Pete

On 12 April 2013 18:11, Alexandre Bourget [email protected] wrote:

But I get another kind of problem.. it's that the fRef inside the
angularFire keeps those fRef.on('value') bound.. and that's what's causing
problems afterwards..

It seems that Firebase is kind of keeping a cache of those URLs we're
passing through.. so keeps the hooks up if you come back and call
angularFire() another time with the same URL..

So I kind of fixed it with:

$scope['$ngFireUnwatch_' + name] = function() {
self._fRef.off('value');
unwatch();
}

otherwise, it was deleting my things.

I thought of using the $scope.. but then my controller,s scope has other
uses.. and I can't clean it up just to trigger one mechanism. And also.. I
think the problem would persist, because it goes inside Firebase.. and its
caching system (didn't look there though).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-16305054
.

from angularfire.

Hmm.. yeah.. and angularFire isn't even listening to $destroy as I can see.. and upon $destroy-ction, if should _fRef.off('value') to make sure it's detached from Firebase too.

Anyway.. I've got something semi-working here.. I'll probably push to my branch if I'm satisfied a bit later. Maybe this will need more reflection.

from angularfire.

We should certainly be adding handling $destroy.

On 12 April 2013 18:33, Alexandre Bourget [email protected] wrote:

Hmm.. yeah.. and angularFire isn't even listening to $destroy as I can
see.. and upon $destroy-ction, if should _fRef.off('value') to make sure
it's detached from Firebase too.

Anyway.. I've got something semi-working here.. I'll probably push to my
branch if I'm satisfied a bit later. Maybe this will need more reflection.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-16306275
.

from angularfire.

Good catch @abourget - as @petebacondarwin suggests handling $destory would be a great start.

from angularfire.

FWIW, you can also use the disassociate callback provided to the promise on resolution (added via pull request #34).

from angularfire.