Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange issue with nested relationship deserializing #230

Open
TAckos95 opened this issue May 20, 2020 · 3 comments
Open

Strange issue with nested relationship deserializing #230

TAckos95 opened this issue May 20, 2020 · 3 comments

Comments

@TAckos95
Copy link

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
Copy link

jun-sheaf commented May 20, 2020

@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 pushed a commit to TAckos95/jsonapi-serializer that referenced this issue May 21, 2020
@TAckos95
Copy link
Author

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
Copy link

jun-sheaf commented May 21, 2020

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. mathematic-inc/ts-japi#2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants