$firebase objects should have an $id #187

Closed
leisms opened this Issue Dec 19, 2013 · 21 comments

Projects

None yet
@leisms
leisms commented Dec 19, 2013

It's sometimes useful to reference an individual item's $id when saving data or for data administration.It's simple to do this with the standard JS Firebase library by using snapshot.name(), but the id doesn't seem to be exposed by $firebase objects. It looks like it would just require setting a variable in the _getInitialValue function.

@katowulf
Member

@ajkochanowicz You're looking at the child data contained in the $firebase object, which does indeed have $id.

However, it doesn't look like the $firebase() object itself has an ID, which is somewhat superfluous since it's in the reference passed into $firebase in the first place.

@leisms you could use this as a workaround:

var ref = new Firebase(URL);
var obj = $firebase(ref);
obj.$id = ref.name();
@leisms
leisms commented Dec 24, 2013

@ajkochanowicz yes, what Kato said, you can get the id's of children objects but not the id of the root object itself.

@katowulf that workaround works, though you'd have to bind two scope variables rather than just one. That seems a little odd when you need to use $id's in practice. I guess this also applies to priority values.

@katowulf
Member

I'm not sure what you mean by two scope vars. But glad it helps : )

@leisms
leisms commented Dec 24, 2013

Np :). Let me elaborate. Here's the use case from the AngularFire Docs:

myapp.controller("MyController", ["$scope", "$firebase",
  function($scope, $firebase) {
    $scope.items = $firebase(new Firebase(URL));
  }
]);

Now in order to access the key of the root object in my template, I would have to change it to this:

myapp.controller("MyController", ["$scope", "$firebase",
  function($scope, $firebase) {
    ref = new Firebase(URL);
    $scope.itemsId = ref.name();
    $scope.items = $firebase(ref);
  }
]);

In order to access the priority of the root object as well, I'd have to write this:

myapp.controller("MyController", ["$scope", "$firebase",
  function($scope, $firebase) {
    ref = new Firebase(URL);
    ref.once('value', function (snapshot) {
      $scope.itemsPriority = snapshot.getPriority();
    });
    $scope.itemsId = ref.name();
    $scope.items = $firebase(ref);
  }
]);

Ideally I would like to setup with the first example, and then access id and priority with items.$id and items.$priority

@anantn does this make sense/any thoughts on how to implement?

@katowulf
Member

FYI - Your third example may not work either. I recall there is some issue with getting the priority off on on('value').

@mikepugh
Contributor

@leisms - couldn't you just do the following to avoid cluttering up your scope?

$scope.items.$id = ref.name();

?

@ncammarata

In my application I relied heavily on passing these IDs around, and it seems to have disappeared. I think it was a good idea to add it originally, and means that I do not have to constantly pass around both IDs and values, but only IDs.

If for some reason we can't have $id on firebase objects, could we at least have a way to go from the angularfire object back to the Firebase ref, and I could hack it by using ref.name everywhere.

@adhsu
adhsu commented Feb 6, 2014

+1 for what @ncammarata mentioned

@mismith
mismith commented Feb 7, 2014

+1 Agreed, these '$id's are handy shortcuts

@tarzain
tarzain commented Feb 7, 2014

+1 @ncammarata i was building something to work around it, but reverting would definitely be better

@katowulf
Member
katowulf commented Feb 7, 2014

Hey Guys. We hear you loud and clear! Anant has a pretty amazing todo list and I promise he'll get to this (if I don't snag it first). It's not forgotten or dismissed.

As far as I interpret this discussion, not having $id is more of a bug than a feature request, so it's not a matter of if it's useful, but simply a matter of priorities and road maps. If this is holding you back, a PR and a test unit would be a huge contribution!

It looks like it might be a straightforward addition, just plopping $id onto the object variable inside of AngularFire::constuct. We just need someone with a few hours allocated to trying it out getting things pushed up.

Cheers,

@anantn
Collaborator
anantn commented Feb 7, 2014

+1 to what @katowulf said, this will definitely be addressed in 0.7 (and will probably be available sooner on master).

@ncammarata

Awesome, thanks guys!

@mikepugh
Contributor
mikepugh commented Feb 9, 2014

Updated PR #240 w/ this, along with a test

@TrkiSF2
TrkiSF2 commented Feb 10, 2014

+1 for the need of the $id

@anantn anantn closed this in 0c5a4d9 Feb 12, 2014
@nikolal
nikolal commented Nov 25, 2014

We want ID.

@jwngr
Member
jwngr commented Nov 25, 2014

This issue is from almost a year ago and is no longer even applicable to AngularFire. Please see our updated documentation, which includes $id on $FirebaseArray and $FirebaseObject. Make sure you upgrade to AngularFire 0.9.0.

@ajbraus
ajbraus commented Oct 22, 2015

+1 I don't understand, the objects themselves don't have id's. You can't even easily create RESTful routing "/projects/:id" without an id attribute. Having the id as the primary identifying attribute of an object is the most universal pattern I've seen in the web. Why abandon it?

@jamestalmage
Contributor

Years old issue. See the docs referenced above.

@jwngr
Member
jwngr commented Oct 23, 2015

@ajbraus - As James said, this is a very old post from two years ago and the API has changed twice in a major way since this issue was created. If you want to carry on a discussion about this, please open a new issue. That being said, every $firebaseObject and each item in $firebaseArray has an $id attribute which specifies the key for the node at which data is stored. We are not shying away from the ID pattern. You can and should use $id as your unique identifier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment