Philosophy/architecture of angular-data about js-data-angular HOT 3 CLOSED

DS.create('post', { author: 'Sally', title: 'Angular gotchas' })
.then(function (post) {
    post; // { id: 65, author: 'Sally', title: 'Angular gotchas' }
});

DS.create('post', { author: 'Sally' })
.then(null, function (err) {
    err; // 'Title is required'
});

What was the design decision around these function signatures?

Why for example is there a separate error callback, rather than an error promise? Or why is the error not returned as the first parameter of the then callback? i.e. .then(...).error(...) or .then(function(error, post)`

from js-data-angular.

@tanepiper angular-data just uses angular's $q service for promises, so they'll function exactly as you would expect $q promises to work. The following are functionally equivalent:

DS.create('post', { author: 'Sally', title: 'Angular gotchas' })
.then(function (post) {
  // called on success
}, function (err) {
  // called on error
})
.finally(function () {
  // always called
});

and

DS.create('post', { author: 'Sally', title: 'Angular gotchas' })
.then(function (post) {
  // called on success
})
.catch(function (err) {
  // called on error
})
.finally(function () {
  // always called
});

The error will never be passed as the first argument to the first callback that was passed to .then(...). It wasn't a design decision on my part–that's just how $q promises work.

Perhaps my example is a bit confusing because I pass null as the first argument to .then(...) (because I knew the first callback wouldn't be called anyway). The examples in this comment are probably clearer.

from js-data-angular.

@jmdobry Ahh I didn't realise that. I've always used the second way though so never seen the first way used. Makes sense now and I'm glad to see they are just promises so fits with my code structuring.

from js-data-angular.