-
-
Notifications
You must be signed in to change notification settings - Fork 52
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
API request result.entities contains records in a different order than they were returned from the server. #123
Comments
@omanizer Yes, this is expected behavior at the moment. I understand your pain, but this is something to do with fondamental of Vuex ORM. Because all the records are normalized and stored at the store, it's a bit hard to restore the original order of the records. Because In this case, we're not sure how we should order the final So the best practice when using Vuex ORM is that to not rely on response order but always query the local records separately using However, I think it would be nice to somehow obtain the original order from the response. Not sure what is the best API, but I think this is worth discussing. |
Describe the bug
This is more of a question but something that might be worth addressing. I have an API endpoint that returns a list of conversations. If I pass in a query string parameter "include_archived" it returns a full list of conversations (including those that have been archived). This endpoint always returns the conversations in order of time descending. It seems that the order of records in the 'entities' property of a request result does not always match the order of records returned from the server. This mainly happens when the server returns some new records and some that already exist in the store.
Steps to reproduce the bug
result = Conversation.api().get('/conversations')
result = Conversation.api().get('/conversations?include_archived=true')
Expected behavior
It would be nice if result.entities could contain the records in the same order that they were returned from the server.
I can manually sort these after the fact but it would be more efficient if sorting could just be assumed since this is being used on an infinite scroll and sometimes users have hundreds of conversations being loaded into a single view.
Versions
Thanks so much for your consideration.
The text was updated successfully, but these errors were encountered: