Weird Issue

[hedder]

https://github.com/jakubrohleder/angular-jsonapi/commit/574663700aede00cda4f9488874892c104e1f9b7#diff-c97eb2f434408bc5e92c61da7210f7ebL2853

• deferred.resolve(_this);
• deferred.resolve(response.data.meta); This change makes the resolved promise to be equal meta information. Is this a typo?

[jakubrohleder]

It's a fix for #3 (the meta part). As the meta information are not strictly connected with the returned object but rather the request itself, I thought it is quite right to resolve promise with them.

I haven't found resolving promise with the object very useful. All of the methods are called for a certain object, so I presumed that the reference to it has been saved somewhere. On the other hand now as you asked the question I think that it might have been useful.

The question is: how to get the request meta but still make the object accessible just with the promise? My only idea is to return an object:

{
  object: object,
  meta: meta
}

What do you think?

[hedder]

As far as I understand it's a part of the document structure and is resolved with the the rest of the document.

{
data: [{}, {…},…],
included: [{}, {…},…],
links: {,…},
meta: {}
}

So deffered.resolve(_this) works perfectly fine. It's resolving the document with all the structure.

Problem is later on when we process data, we cut off meta information. It should be just passed through.

    _this.meta = response.data.meta; 

will probably do the job

[jakubrohleder]

I'm not sure if you think about same thing as I do, so to clarify on the simplified save method example:

function save() {
  _this.synchronize(config).then(resolve, reject, notify);
  // The synchronizer.synchronize is called, synchronizer asks each Source for data, 
  // combines answers and resolves promise

      function resolve(response) {
        // response from synchronizer is:
        //{
        //  data: {
        //    data: [{}, {…},…],
        //    included: [{}, {…},…],
        //    links: {,…},
        //    meta: {}
        //  },
        //  errors: {..},
        //  finishCallback: foo
        //}

        _this.update(response.data.data);
        // object is updated with data but it cannot be updated with meta like:
        _this.meta = response.data.meta
        // because in this way the object meta property would possibly change
        // with each request, moreover meta data can e.g. have a copyright info
        // that has nothing to do with the object

        // Now we want to resolve the save method that was called on the object:

        // we can do it with an object itself
        deferred.resolve(_this);

        // we can do it with meta
        deferred.resolve(response.data.meta);

        //we can do it with the whole resonse
        deferred.resolve(response);
      }

  return deferred.promise;

The flow is more or less similar when it comes to other methods for Objects and Collections. Please not that when we call deferred.resolve _this refers to object on which the method has been called, not to the server response document.

I'm not the best at explaining things, so if something is unclear don't hesitate to ask.

[hedder]

Yes, we don't exactly understand each other on words. Examples will work better

Here the line of code

It carries 'links' from 'response' to the object. I am offering to do the exact same thing for 'meta'.

[jakubrohleder]

Yep now I see what you mean, but I don't want to make meta a part of an object, although it seem similar to links.

Links provides information about the object itself while meta provides information about one particular request to server (may include copyright, request processing time, returned object count etc.). In your solution object.meta would represent meta data of the last request that somehow affected this object.

That's why adding meta as an object property (like links) doesn't seem to be reasonable for me. Instead I prefer to return them when each request is resolved.

[hedder]

Now I see what was the purpose of resolving meta At some point I thought it was a typo Your solution is good performance-wise