Strange issue with nested relationship deserializing

[TAckos95]

I found one very strange bug working with this library. What happens is that in some cases nested relationships (which are included as well in "included" list) do get serialized and sometimes they don't. I actually took the example from your tests (this one), pasted it beside my non-working example, adapted both to look exactly the same, and tried to figure out what went wrong.

Conclusion is very strange. Apparently when "data" type has "relationship" type on it's beginning, that relationship won't resolve it's relationships even though they are included. It sound's strange, but here is an adapted example taken from earlier mentioned tests.

const testData = {
  data: {
    type: "user",
    id: "54735750e16638ba1eee59cb",
    attributes: {
      "first-name": "Sandro",
      "last-name": "Munda"
    },
    relationships: {
      address: {
        data: { type: "address", id: "54735722e16620ba1eee36af" }
      }
    }
  },
  included: [
    {
      type: "address",
      id: "54735722e16620ba1eee36af",
      attributes: {
        "address-line1": "406 Madison Court",
        "zip-code": "49426",
        country: "USA"
      },
      relationships: {
        lock: {
          data: { type: "lock", id: "1" }
        }
      }
    },
    {
      type: "lock",
      id: "1",
      attributes: {
        "secret-key": "S*7v0oMf7YxCtFyA$ffy"
      }
    }
  ]
};

new Deserializer({
  keyForAttribute: "camelCase",
  pluralizeType: false
})
  .deserialize(testData)
  .then(res => console.log(res));

In given example, console would look as expected, it would have user attributes, and address attribute containing all of the "address" relationship attributes and lock attribute, containing all of the "lock" relationship attributes.

{
  firstName: "Sandro",
  lastName: "Munda",
  id: "54735750e16638ba1eee59cb",
  address: {
    addressLine1: "406 Madison Court",
    zipCode: "49426",
    country: "USA",
    id: "54735722e16620ba1eee36af",
    lock: {
      secretKey: "S*7v0oMf7YxCtFyA$ffy",
      id: "1"
    }
  }
}

But, if you change top level data type from "users" to "addressUsers" (or anything that starts with "address") it would just skip "lock" part, and the result would look like this:

{
  firstName: "Sandro",
  lastName: "Munda",
  id: "54735750e16638ba1eee59cb",
  address: {
    addressLine1: "406 Madison Court",
    zipCode: "49426",
    country: "USA",
    id: "54735722e16620ba1eee36af",
  }
}

I'm not sure how is that possible, or what is going on in the background, but this is a real problem for me, and it'd be great if someone could check it out and even provide a solution for it.

Thanks in advance!

[jun-sheaf]

@TAckos95 So I have been going around looking for those who are struggling to find a proper JSONAPI serializer.

Over the past few days I've designed a resource-recursive, typescript/javascript library for serializing the entire JSON:API spec. Our API is far more fluent (and obvious) than the one here (and every other serializer I have seen/used). If this serializer doesn't fit your need, you might want to check it out :) Development is active.

If you are in particular struggling with issues such as links, resource relationships, and deep recursion (essentially any of the complicated parts of the JSON:API spec), I strongly recommend moving to our library.

{TS:JAPI}: https://github.com/jun-sheaf/ts-japi

[TAckos95]

Update: Issue doesn't exist on version 3.6.5, so I traced the problem back to the commit which is resolving some circular dependencies ("Use recursive tracking through relationship branches to avoid circula…"), and exactly to this line.

So this problem is solved with downgrading the version. But then actually there are problems with circular dependencies, which are even worse than this one. So I created a [fix]() for it (waiting for merge).

@jun-sheaf thanks for the info. I checked it out, and a problem I found with it is that it doesn't have a deserializer implemented yet, and this issue is in regarding to deserialization of data.

[jun-sheaf]

Update: Issue doesn't exist on version 3.6.5, so I traced the problem back to the commit which is resolving some circular dependencies ("Use recursive tracking through relationship branches to avoid circula…"), and exactly to this line.

So this problem is solved with downgrading the version. But then actually there are problems with circular dependencies, which are even worse than this one. So I created a [fix]() for it (waiting for merge).

@jun-sheaf thanks for the info. I checked it out, and a problem I found with it is that it doesn't have a deserializer implemented yet, and this issue is in regarding to deserialization of data.

I see. Well we are trying to implement a deserializer. The issue lies in trying to do it properly. We currently have an issue up if you would like to contribute your opinion. https://github.com/jun-sheaf/ts-japi/issues/2