Suppose you have a use case where you have a repeatable custom type, but you want to have the documents arranged in a specific order.
What I think would be ideal is that you have default views for each custom type you define,
e.g. when you have a Product Category type, that you would have a "Product Category View" where you would see all product categories. This is similar to how you filter the documents currently, but with only one filter applied at a time.
If you have a unique view for each type, you could then allow custom ordering. When a custom order has been defined, we query the GraphQL API and get all documents in the custom order. Currently this is only achievable if you create another document type, e.g. Product Category Page, and then add all product categories again by links.
IMO it would make the UI more structured as well having these views for each type.
OK, I think I understand now. You're suggesting that you can define an order of documents manually in the writing room. So for example, we have:
[ Doc A ]
[ Doc B ]
[ Doc C ]
[ Doc D ]
You want to be able to manually move these and have them appear in the UI as something like:
[ Doc D ]
[ Doc B ]
[ Doc A ]
[ Doc C ]
and then be able to query the API to get them in that manually defined order?
Is that correct? If so, I can see how this can be useful. Although, I'm not sure how this is more efficient than having a Product Category Page as you suggested.
Also, how document orderings appear in the UI does not affect the API, the UI basically queries the API to create its document list and is therefore restricted to the query options that exist there. Meaning to do something like this we would have to create extra documents in your repositories API.
So creating a Product Category Page is the only functional way you could do something like this and send it to the API.
I do realise it's currently only possible through the extra document, .e.g. Product Category Page.
However, it's a lot of extra work. Suppose you have a big list of items that need to be in a custom order, say 50 items. Then you would first need to create all 50 documents, then go to the product category page and add them again to a field so you can order them.
IMO, it would also be cleaner when querying the API. Let's take the Product Category example. If we would want to list the product categories in a specific order on several pages, it would make sense to just fetch the product categories from the GraphQL API, and not fetch another document that has links to the categories. The ideal scenario would be the following query:
You don't really want to have the order linked to a field of another document. That's why I think it would really benefit Prismic in general if you would restructure the UI a bit and have a section for each custom type that contains only those documents.
You could even extend the functionality I'm proposing and allow parent/child relations in these views (by dragging a document below another document in the view).
Yes, I can see how that could be useful and easy to manage. I've logged your feature request in our tracker, although this is not currently in our plans to work on this. If/when there are any updates regarding this the team will contact you here.
Thanks.
Phil
(Phil Snow)
closed , flag & select 'Something Else' to reopen.
8