Duplicate type + id in included, but different data. about json-api-serializer HOT 7 CLOSED

Hi @wesselvdv,

Thanks for your work.
This library has the responsability to serialize a data to be JSONAPI spec compliant, and to deserialize this JSONAPI payload back to original data.

E.g For this input data with 3 objects :

[{
    id: '1',
    body: 'test body 1',
  }, {
    id: '2',
    body: 'test body 2',
  }, {
    id: '1',
    body: 'test body 1',
    additional: 'test additional 2',
  }];

After serializing, you will have an array of 2 objects.

How can the library will convert it back to original data (with 3 objects) ?

from json-api-serializer.

The issue that I am facing is that those 3 objects are actually two objects. Where the objects that have the same id are the same entity, but one has more information loaded than the other. Hence the fact that I want them to be combined before they are sent off to the client.

I completely understand that this is a trivial example where one might easily correct that situation beforehand, but I have deeply nested objects with complex relations that are harder to recursively deduplicate, and/or merge.

I this case when converted back it puts it back together more efficiently than I originally created it.

from json-api-serializer.

If we add a transform option function to transform each record before the serialization on serializeData. Can that match your specific case ?

from json-api-serializer.

Hmm, that could work if the callback is provided type, id, and the obj itself. It would be awesome if we could also customize the deduplication function. Not sure if that one’s running only running on included?

from json-api-serializer.

Just joining in to give another opinion to the mix:
I think this shouldn't be part of this library, but it should be done before or after the serialization. Checking every data item against each other for uniqueness by doing a deep-comparison does not scale well. It's already happening for included resources, which is necessary, since it's quite normal for nested data-relations to contain redundant data.

But your case seems to be a really rare edge-case. And since there's a workaround by merging duplicates in data after or before the serialization, I wouldn't add this complexity and probably negative performance-impact to this library.

from json-api-serializer.

I agree with @Mattii, I was already not very convinced to add it for complexity reasons for a very specific need.

from json-api-serializer.

I did indeed do what you suggested. Funny thing is that for me incorporating this into api-serializer somehow is more efficient than iterating over the list afterwards. I do agree with both of you, my case is rather edgy.

Closing, :-).

from json-api-serializer.