js-data / js-data-angular Goto Github PK

Still need to add:

• - Queries and filtering guide
• - Writing your own adapter guide

Takes a query like DS.findAll but destroys the items from the server and the data store.

I have no clue if this is an angular-data issue or if its just something in my code.

I am showing a loading indicator that shows when there are pending promises and it works everywhere except for one of my pages. I logged how many promises were still pending and it always shows 2.
Here is the code that decorates $q:

        $provide.decorator('$q', ['$delegate', '$rootScope', '$log', function ($delegate, $rootScope, $log) {
            var pendingPromisses = 0;
            $rootScope.$watch(
                function () {
                    return pendingPromisses > 0;
                },
                function (loading) {
                    $rootScope.loading = loading;
                }
            );
            var $q = $delegate;
            var origDefer = $q.defer;
            $q.defer = function () {
                var defer = origDefer();
                $log.debug(defer);
                pendingPromisses++;
                defer.promise.finally(function () {
                    pendingPromisses--;
                });
                return defer;
            };
            return $q;
        }]);

If I comment the following code I don't have the issue any more. Also it seems like this is making two requests to the server.

DS.find('class', $stateParams.id)
    .then($log)
    .then(function(gbClass){
        $scope.gbClass = gbClass;
    });

See the Design Doc for more reading.

One of the things that developers either love or hate about Angular is its use of POJOs and not decorated objects like Backbone or Ember. I personally like POJOs, and I think angular-data should stick with them.

Angular-data won't decorate your data, but it will maintain meta data about your data for its operation. That means that you can manipulate your data directly obj.foo = 'bar', but any asynchronous operations on your data must be performed through angular-data's API DS.save('document', 45).then(...).

Angular-data aims to be very pluggable and adaptable. I don't know how big it will be, but angular-data could be engineered to support swappable plugins that angular-data uses at runtime.

Example:

• angular-data.js
• angular-data-pouchdb.js
• angular-data-indexeddb.js
• angular-data-goinstant.js
• angular-data-firebase.js

angular-data should be configurable to use an AJAX adapter for asynchronous data retrieval.

Other possible adapters include:

• IndexedDB
• localStorage
• What else?

Devs should be able to $watch two different meta properties of objects in the store to stay up-to-date with the latest version of those objects.

lastSaved - A timestamp of the last time an object was saved via an async adapter
lastModified - A timestamp of the last time any of the properties on an object changed

Examples:

$scope.$watch(function () {
  return DS.lastSaved('document', 45);
}, function (lastSavedTimestamp) {
  $scope.document = DS.get('document', 45);
});

In the above example the document on the $scope is only updated when the object is saved to the server. This is useful when you don't want the data binding in a form updating the object all over the screen when the user hasn't clicked the save button yet.

$scope.$watch(function () {
  return DS.lastModified('document', 45);
}, function (lastModifiedTimestamp) {
  $scope.document = DS.get('document', 45);
});

The above example would be more efficient than the following:

$scope.$watch(function () {
  return DS.get('document', 45);
}, ...);

because internally angular-data would use Object.observe if available, else its own digest loop that performs dirty checking just like Angular. Maybe devs should be able to throttle this digest loop as well.

This digest loop would be kicked off whenever $rootScope's digest loop runs. Maybe it can be configured to run on an interval.

• Can angular-data by required via browserify?
• Can angular-data be loaded by AMD?
• Make sure npm install builds angular-data properly so it can be required.

That way the dev has the option to either manually inject the data into the store or discard it.

I can do this currently, I just wanted to bring this to your attention so people don't start passing options to defineResource and screw themselves up when you want to add features... For example...
I'm using angular-data today and do this:

DS.defineResource({
  name: 'user',
  foo: 'bar'
});

Then tomorrow, you decide that we really need to add another option to defineResource and we want to call it foo.

I upgrade.

The internet breaks... Or something...

Here's my proposed solution: Give us a field for stuff like this called meta and then explicitly create the definition, don't just make the object we pass you as the definition. We will hate ourselves later I'm sure...

• - API complete
• - Guide complete
• - Site build/deploy ready

It would be great if angular-data support automatic validation and schemas. These would be optional/pluggable, meaning that devs could provide their own or use something provided by angular-data out of the box.

I'd like to use the robocop.js for schema definition and validation. robocop could be bundled with angular-data. angular-data could have a "light" build that doesn't come with robocop.

i wonder if you are informed of nag-rest

can you please provide a comparison with that project (either current angular-data features or what it wants to be )

DS.save and DS.destroy should support lifecycle hooks.

When defining a resource devs should be able to provide beforeCreate and afterDestroy functions, for example, that are executed at the appropriate time in a model's life cycle.

I have a user resource and I want to add functionality to it to make things easier to work with. For example, with ngResource I did something like this:

var User = $resource(BaseUrl + '/api/v1/rest/users/:id', { id: '@_id' });
User.prototype.getDisplayName = function() {
  if (this.name.first && this.name.last) {
    return (this.name.first || '') + ' ' + (this.name.last || '');
  } else if (this.username) {
    return '@' + this.username;
  } else {
    return 'Anonymous';
  }
};

So, with the direction that angular-data is going, would you recommend:

1. Have a UserControllerService or something that would act on the POJO
2. Hook the lifecycle of the resource (like afterCreate) and return a new User(data) version of the POJO?

Looking forward to using this and hopefully providing good feedback and PRs 👍

Takes a query like DS.findAll but just removes the matching items from the data store.

• - Audit performance of observable objects
• - Verify reliability of the digest/dirty checking that's tied to $rootScope

Hi, I am trying to test the angular data under my application, by I thing I do something wrong, because I keep getting the following error:

Error: [$injector:unpr] Unknown provider: aProvider <- a <- $q <- $http <- $compile http://errors.angularjs.org/1.2.16/$injector/unpr?p0=aProvider%20%3C-%20a%20%3C-%20%24q%20%3C-%20%24http%20%3C-%20%24compile

I tried both 0.7.1 and 0.8.0 versions, and removed every other dependency from the app to ensure that this is not caused by some conflict.
Any help will be more than appreciated.

The angular-data query language has to do with the filter and findAll methods. The same query object should be able to be passed into filter and findAll and they should return the same result. filter synchronously returns data from the store. findAll asynchronously retrieves data from the server.

The query language used by angular-data needs to be:

• simple
• extendable
• adaptable

Devs should be able to write query translators that translate angular-data's query language to the query format supported by their app's REST API. Normally the query object would get serialized to the search query in the request parameters. Devs should have the option to transform the url to something their REST API before the request is sent.

By default angular-data should return references to the objects that reside in the store. Example:

DS.get('document', 45); // reference to { id: 45, title: 'How to Cook' }

Perhaps their should be a separate method for retrieving a copy:

DS.getCopy('document', 45); // copy of { id: 45, title: 'How to Cook' }

Sometimes a copy is useful because you can modify it directly without dirtying the object in the store.

By default angular-data remembers each query that has been made. For example:

DS.findAll('document', { query: { limit: 20 } });

When this same query is made again angular-data immediately resolves the promise with the result of DS.filter('document', { query: { limit: 20 } });

Devs should have the option of invalidating a particular query to force angular-data to run the query through the async adapter (AJAX, IndexedDB, etc).