Philosophy/architecture of angular-data

[jmdobry]

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

[tanepiper]

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)`

[jmdobry]

@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.

[tanepiper]

@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.