Update and fix the examples

[jukkakoskinen]

Some of the usage examples seem to be broken, for example the query function...

$scope.posts = Post.query({
    page: 1
});

...doesn't return a collection like the example suggests. Tested on Angular 1.0.7 & 1.1.5 with the following code:

app.factory('User', function (firebaseResource) {
    var User = firebaseResource({
        path: 'users',
        hasMany: ['Post']
    });

    return User;
});

app.factory('Post', function (firebaseResource) {
    var Post = firebaseResource({
        path: 'posts',
        belongsTo: true,
        perPage: 10
    });

    return Post;
});

app.controller('PostsCtrl', function ($scope, Post, User) {
    $scope.user = User.query()[0];
    $scope.posts = $scope.user.posts().query({
        page: 1
    });
});

Sorry I couldn't get a Fiddle up to demonstrate the problem...

[marknutter]

In my app I exclusively use query on associations, not standalone models, so I'm not sure it was ever working properly. I'll get this working ASAP. Thanks!

[marknutter]

@jukkakoskinen Ah, I see the issue. query() is working fine on models without associations after all, but I didn't make it clear how it's supposed to be used. the query() method sets up the listeners for a model but doesn't actually return the results. You have to use the all() method to get at the results for a model. So to modify the example:

app.controller('PostsCtrl', function ($scope, Post, User) {
    User.query();
    $scope.user = User.all()[0];
    $scope.user.posts().query({page:1});
    $scope.posts = $scope.user.posts().all();
});

I'll fix this in the readme and whip up a working example as well.

[jukkakoskinen]

Sweet, thanks. I'll try this out!

[jukkakoskinen]

Yeah, calling Resource.all()[0] right after a query won't work though. You can test this by logging the return value after a non-cached query (= data fetched from Firebase), and logging it again after a small timeout.

Post.query();
console.log(Post.all()[0]); // is undefined
$timeout(function() {
    console.log(Post.all()[0]); // is a valid resource
}, 1000);

Makes kinda sense, since it's not deferred.

[marknutter]

Well, query returns a promise so perhaps any calls to all() should be done in the resolved promise from query(). so:

Post.query().then(function() {
    Post.all()
});

The idea is to bind all() to a template and use filters from there. The array returned from all() should automatically update as items come in from Firebase. So a call to all() isn't really intended to go out and get anything, it's just a shortcut to the store that all Firebase objects for that model are contained in, which will constantly be changing.

I did it this way because of the dynamic nature of Firebase. Asking for "all" items when dealing with a realtime scenario is different than when dealing with a standard REST API. The definition of "all" is constantly in flux. I hope that makes sense.

[marknutter]

The latest commit has two examples that hopefully make things more clear. In example_2.js you'll see I'm binding user.posts().all() directly in the template in index.html:

<ul>
  <li ng-repeat="post in user.posts().all()">
    {{post.content}}
  </li>
</ul>

In the controller we call:

$scope.user.posts().query();

and as new posts come in from Firebase they are automatically updated by the view digest cycle.

[jukkakoskinen]

Alright. The examples cleared it up, thanks!