Collection list: allow a default sort, and control over the Slug column

[renatomprado]

Two small gaps in the collection list view (packages/keystatic/src/app/CollectionPage.tsx). They're separate asks but they live in the same component, so I'm filing them together.

1. Default sort is fixed to slug ascending

let [sortDescriptor, setSortDescriptor] = useState({
  column: SLUG,
  direction: 'ascending',
});

For a blog, alphabetical-by-filename is close to random order, and the useful default is newest first. You can click the date column header, but it resets on every reload, so the editor re-sorts constantly.

parseSlugForSort exists, but it changes how the slug column sorts rather than which column is used, so it only helps when the date is part of the filename — which it isn't when the slug is the URL.

Proposal: an optional defaultSort on the collection:

defaultSort?: { column: string; direction: 'ascending' | 'descending' }

falling back to today's behaviour when absent.

2. The Slug column is always second and can't be hidden

return [
  ...(hideStatusColumn ? [] : [statusColumn]),
  { name: 'Slug', key: SLUG },
  ...collection.columns.map(...),
];

columns controls the configured columns and their order, but Slug is fixed ahead of them.

This matters most when slugField points at the title, which I'd guess is the common setup. Then the list shows the same text twice — once in kebab-case as Slug and once as the Title column — and the duplicate takes the more prominent position. My client's list reads:

Slug	Data de publicação	Título
dores-no-climaterio	2026-08-05	Dores no climatério: o que muda no corpo depois dos 40

The slug is developer information. She doesn't need it, and it's the second thing she sees.

Proposal: either let columns include the slug explicitly (so its position is up to the config), or add something like showSlugColumn?: boolean. The first is more flexible; the second is a smaller change and probably enough.

Context

Two Keystatic Cloud panels used by non-technical clients in Brazil. Related to #1578, but independent — that one is about strings, this is about the list view. Happy to send a PR for either or both if you're open to the shape.

[renatomprado]

A third one for the same view, since it comes from the same session of watching a client use the panel: editing a simple field directly from the list.

The concrete case is a draft/published flag. Today changing it means opening the entry, changing one field, saving, and going back — for what is conceptually a toggle. With a dozen posts that's the most repeated action in the panel.

I realise this is bigger than the other two, because the list is a read view and every write in Keystatic is a commit: it would need a confirmation path, an error state, and a "saving" indicator. So I'm filing it as a want, not a proposal.

Worth noting a smaller adjacent issue I hit on the way. Columns render the raw stored value:

val = item.data?.[column];
val = val == null ? undefined : val + '';

So a fields.checkbox column shows "true" / "false" — literal, and in English regardless of locale. For a non-technical editor that's worse than no column at all, since they have to remember which value means draft. I worked around it by changing the field to a fields.select storing "Publicado" / "Rascunho", which renders the word itself.

That workaround has a cost worth naming: the stored values are now display strings, so the content schema carries UI concerns. If cells rendered a checkbox (or the option's label rather than its value) for those field types, the natural boolean would be usable again.