-
Notifications
You must be signed in to change notification settings - Fork 38
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
Question about sorting of included resources by id #51
Comments
Hey, Fair question! The "included" array should be considered as an Identity Map, so ordering its content by ID seemed reasonable for aesthetics, in spite of the fact that doing so has no practical advantage to be honest. Based on my understanding, that's why JSON:API clients shouldn't rely on the order of the included resources: the "included" array should be first loaded in memory, and when querying the response, the client should retrieve included resources for a relationship by associating them with resource identifier objects - which are correctly sorted. But I am eager to hear your use-case! Maybe it can confirm that this ordering should be removed. |
Hi, thanks for your answer! In general I agree with you that the included resources order should not be considered as important, but the relationships array to be used instead. In my use-case I use normalization of the JSONAPI response, based on this normalizer. As you could see here, it combines all entities from data + all entities from included resources and groups them by type, so they are easier to access after that. The final result is shown in the README. Please let me know what do you think and if it makes sense. I am currently trying to find out the best way to fix the problem and I should change the code of the normalizer in my client, if you think that it's better not to rely on the included resources order. |
OK, now I understand your problem. :) I did some investigation and fortunately found a discussion about sorting the included array: http://discuss.jsonapi.org/t/how-to-sort-included-resources/198. This means that I am willing to remove sorting because it isn't controversial to the spec and recommendations and this modification even improves the performance a tiny little bit. However, the included array won't be so neatly arranged as it is today. :P By the way: does your normalizer handle cases well when there are multiple types in a relationship data? Just for reference, I link a really interesting conversation here about the included array, maybe you find some insights there: http://discuss.jsonapi.org/t/why-is-included-an-array/76 Sorry if you have already seen it. :) So I am going to release 1.0.2 in the following days with the aforementioned modification :) Thank you for your question! |
Very nice resources, thanks! I haven't read them so far and I will very soon. It's nice that you think the included array can be sorted too and it is not against the specifications. Waiting for this improvement, even it wouldn't look so neat any more ;) Yes, the normalizer handles multiple included resources types and as it uses the included array to iterate trough them and group them, it's a relatively easy task. For example:
becomes
You can even see how the ordering of the experience and education relationships is different in relationships and included arrays and how the normalizer uses the included ordering, which is the reason to open this question :) |
Released v1.0.2 :) P.S.: It's nice to hear that the normalizer handles this case too! |
Hi,
I noticed, that in my JSONAPI response the included resources are sorted by id, instead by their original order.
After looking in the code I found out that this line sorts them by id.
I have a question, why is this behavior implemented? In my case I would like to have them sorted in the same way, in which they come from the DB and like they are sorted in the relationships data array. Am I missing something?
Thanks in advance!
The text was updated successfully, but these errors were encountered: