Feature request: scope ordering by another property

[fabien]

Hi Bret,

Thanks for this plugin, it's really useful!

One thing I do miss quite often, is the ability to scope the ordering based on another property. For example, in a nested structure, it would be handy to limit the ordering of child nodes within their parent. Think categories, with the items in each category to be listed in a user-defined order (currently, I would reference the categories from the parent in an array, but this isn't always ideal - especially since this is still pending: https://github.com/sanity-io/sanity/issues/507).

So essentially, the scope would be the parent _ref. Ideally it would be possible to specify such a scope using GROQ, for example: parent._ref or parents[0]._ref (when multiple parents are allowed). An array of such scopes would be even better.

When it comes to the UI, it would make sense to have another dropdown to show all these 'facets' as a listing of known parents. When selecting it, only those items would be shown in order for them to be reordered.

However, the ideal solution would be some sort of Desk Structure integration, so the list items themselves would become reorderable ... one can dream, no? This is probably something that would somehow be part of Studio core someday ...

[BretCameron]

Hi Fabien, are you talking specifically about nested documents? For example, cast members nested within a movie object:

You can already order these within the Desk view, so I suspect I am misunderstanding!

Or maybe you mean something along the lines of "Order all movies, showing only those with a genre property"?

[fabien]

Hi Bret, it depends on where your relation is maintained.

If you are keeping an array of children, like your Cast Members, then you can easily manage those using the Desk view.

What I am referring to is when the relation is established using a 'foreign key', most likely in a 1:n relationship. This is often preferred, as it doesn't require the parent document to be aware of all its children. It's certainly quite practical once you go beyond a certain number of items to maintain that way.

This is a common pattern in MongoDB, but it applies to Sanity just as well I believe: https://docs.mongodb.com/manual/tutorial/model-referenced-one-to-many-relationships-between-documents/

So for example, a node document which refers to a parent. Such parent can have many child nodes:

{
  name: 'node',
  type: 'document',
  fields: [
    {
      name: 'name',
      title: 'Name',
      type: 'string'
    },
    {
      name: 'parent',
      title: 'Parent',
      type: 'reference',
      to: [{ type: 'node' }] // recursive, but could be another document type as well
    },
    {
      name: 'order',
      title: 'Order',
      type: 'number',
      hidden: true
    }
  ]
}