Decision to use node cb style for lifecycle hooks

[clark-pan]

Is there a specific reason why you chose to use the nodejs cb style for the lifecycle hook functions?

Since we've got promises anyways, and internally it seems like you convert them into promises (by decorating $q, which isn't a very good idea) why not just wrap the return value in a $q.when?

So instead of:

promise
  .then(function (attrs) {
    return DS.$q.promisify(definition.beforeValidate)(resourceName, attrs);
  })

why not:

promise
  .then(function(attrs){
    return definition.beforeValidate(resourceName, attrs);
  })

It would provide consistency in within the library and application code in how async is handled.

[jmdobry]

My original reasoning? I wanted the hooks to be asynchronous, but I didn't want to force developers to create promises. By using callbacks, developers don't have to wrap any callback-based api they might use in a hook with a new promise. I didn't want to just assume that devs use $q for everything and only use promise-based code. Using $q.when precludes use of callbacks. Callbacks do not preclude the use of promises.

Right now I am in the process of making angular-data usable in any framework, in which case I certainly cannot rely on devs being able to use $q.

I do agree however, that the api should be more consistent. You should be able to just return a promise inside a lifecycle hook if you don't use the callback. PR?

[clark-pan]

@jmdobry Done

[jmdobry]

Fixed by #177