payload
payload copied to clipboard
payloadcms
feat: local / REST sort by multiple fields
Description
Adds ability to use native mongo "sort" object https://mongoosejs.com/docs/api/query.html#Query.prototype.sort(), so we can sort by multiple fields, localized fields are also retrieved before passing to mongo
Default behaviour when using string "sort" property is not changed.
Discussion #2089, also personally i need this in my projects (my case for example is Posts should sort by "isFavorite" and by "createdAt" after that)
Only in Local / REST API for now... (upd: i think graphql support requires adding buildSortInpuType that can be string or object with allowed for sorting fields from collection like buildWhereInputType, or ScalarType will be probably fine? i don't know what would be "right" way to do this)
Example
http://localhost:3000/api/sort-multiple?sort[bool]=1&sort[number]=1
payload.find({
collection: "sort-multiple",
sort: {
bool: 1,
number: 1,
}
})
[
{
"id": "64eba770bfd35597698618d3",
"number": 30,
"bool": false,
"createdAt": "2023-08-27T19:43:44.744Z",
"updatedAt": "2023-08-27T19:43:44.744Z"
},
{
"id": "64eba770bfd35597698618d4",
"number": 5,
"bool": true,
"createdAt": "2023-08-27T19:43:44.744Z",
"updatedAt": "2023-08-27T19:43:44.744Z"
},
{
"id": "64eba770bfd35597698618d2",
"number": 10,
"bool": true,
"createdAt": "2023-08-27T19:43:44.744Z",
"updatedAt": "2023-08-27T19:43:44.744Z"
}
],
http://localhost:3000/api/sort-multiple?sort[bool]=1&sort[number]=-1
payload.find({
collection: "sort-multiple",
sort: {
bool: 1,
number: -1,
}
})
[
{
"id": "64eba770bfd35597698618d3",
"number": 30,
"bool": false,
"createdAt": "2023-08-27T19:43:44.744Z",
"updatedAt": "2023-08-27T19:43:44.744Z"
},
{
"id": "64eba770bfd35597698618d2",
"number": 10,
"bool": true,
"createdAt": "2023-08-27T19:43:44.744Z",
"updatedAt": "2023-08-27T19:43:44.744Z"
},
{
"id": "64eba770bfd35597698618d4",
"number": 5,
"bool": true,
"createdAt": "2023-08-27T19:43:44.744Z",
"updatedAt": "2023-08-27T19:43:44.744Z"
}
]
http://localhost:3000/api/sort-multiple?sort[bool]=-1&sort[number]=-1
payload.find({
collection: "sort-multiple",
sort: {
bool: -1,
number: -1,
}
})
[
{
"id": "64eba770bfd35597698618d2",
"number": 10,
"bool": true,
"createdAt": "2023-08-27T19:43:44.744Z",
"updatedAt": "2023-08-27T19:43:44.744Z"
},
{
"id": "64eba770bfd35597698618d4",
"number": 5,
"bool": true,
"createdAt": "2023-08-27T19:43:44.744Z",
"updatedAt": "2023-08-27T19:43:44.744Z"
},
{
"id": "64eba770bfd35597698618d3",
"number": 30,
"bool": false,
"createdAt": "2023-08-27T19:43:44.744Z",
"updatedAt": "2023-08-27T19:43:44.744Z"
}
]
- [x] I have read and understand the CONTRIBUTING.md document in this repository.
Type of change
- [x] New feature (non-breaking change which adds functionality)
- [x] This change requires a documentation update
Checklist:
- [ ] I have added tests that prove my fix is effective or that my feature works
- [x] Existing test suite passes locally with my changes
- [ ] I have made corresponding changes to the documentation (honestly i don't know how to correctly change current
sortsection in doc according to my changes)
If someone want to use it now, i created this gist with "patched" payload find operation https://gist.github.com/r1tsuu/4de3e253cde7bf9693bec0a5ca78735a just copy findHandler.ts to your project and in your collection replace endpoint / GET.
const Pages: CollectionConfig = {
/// ...,
endpoints: [
{
path: '/',
handler: findHandler,
method: 'get',
},
],
}
Of course it would be better if it was in Payload
Hello, any updates? Probably it would be better for me to back with this PR when 2.0 with Drizzle ORM will be released?
My apologies for missing this. The timing wasn't great from the switch to 2.0. We would be happy to get it added into the latest version.
Is there any expected update on this in 2.X or 3.X?
Honestly i would like to continue working on this, i think any ORM should have this, and Payload especially now is more like an ORM thing for medium+ projects. But i would like to see maybe some feedback about how i implemented it here and any suggestions. Also should i work with 3.0 alpha(beta?) branch or main/both?
agree, that this functionality is almost essential for ORMs, especially for quite long lists of data. Not sure if I can answer the other questions as just recently started using payload. But would like to keep the conversation alive :) The implementation looks solid, just wonder why User interface was affected. As for the version is 1.X maintained at all? I thought 2 and 3 are the only ones to go for now.
agree, that this functionality is almost essential for ORMs, especially for quite long lists of data. Not sure if I can answer the other questions as just recently started using payload. But would like to keep the conversation alive :) The implementation looks solid, just wonder why User interface was affected. As for the version is 1.X maintained at all? I thought 2 and 3 are the only ones to go for now.
no, it's not maintained, i'd need to pull 2.0 (main) / 3.0alpha and then work with it or just new pr probably
I would like to see this get in to 2.x and 3.x.
When we made the DB adapter interface I purposefully dropped the type for sort back to a simple string. Then sort would be written to work with any incoming formats of comma separated field names:
-
title -
-title -
title,createdAt -
meta.title,title -
title,createdAt,asManySortFieldsAsYouLike, etc.
This seemed more straightforward of an approach than a more complex array or whatever. The sort query param would work just fine with any of these as well that way. ?sort=whatever,you,do,is,fine.
I'm interested in hearing feedback on this. Would you prefer a more expressive type or just let it be type string?
I would like to see this get in to 2.x and 3.x.
When we made the DB adapter interface I purposefully dropped the type for sort back to a simple string. Then sort would be written to work with any incoming formats of comma separated field names:
title-titletitle,createdAtmeta.title,titletitle,createdAt,asManySortFieldsAsYouLike, etc.This seemed more straightforward of an approach than a more complex array or whatever. The sort query param would work just fine with any of these as well that way.
?sort=whatever,you,do,is,fine.I'm interested in hearing feedback on this. Would you prefer a more expressive type or just let it be type
string?
I think string is fine really as it would be consistent with what we have now.
