feat: local / REST sort by multiple fields

[r1tsuu]

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"
    }
  ]

• I have read and understand the CONTRIBUTING.md document in this repository.

Type of change

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

Checklist:

• I have added tests that prove my fix is effective or that my feature works
• 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 currentsort section in doc according to my changes)

[r1tsuu]

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

[r1tsuu]

Hello, any updates? Probably it would be better for me to back with this PR when 2.0 with Drizzle ORM will be released?

[DanRibbens]

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.

[ppkinev]

Is there any expected update on this in 2.X or 3.X?

[r1tsuu]

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?

[ppkinev]

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.

[r1tsuu]

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

[ppkinev]

the new PR prob would be the safest choice

[DanRibbens]

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?

[r1tsuu]

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 think string is fine really as it would be consistent with what we have now.

[denolfe]

We'd accept a PR for this against beta/3.0. Closing this old one.

[andershermansen]

Created a new PR with multiple fields sort against beta branch: #8799