AdminCollectionConfigInput
Defined in: packages/core/src/collections/types.ts:295
Admin panel configuration input for a collection.
Controls how the collection is presented and queried in the admin panel. All properties are optional.
Defaults applied by defineCollection():
{ useAsTitle: "_id", // falls back to the Convex document ID if not set}Example
Section titled “Example”defineCollection({ slug: "posts", fields: { title: text({ required: true }) }, admin: { useAsTitle: "title" },})AdminCollectionConfig for the resolved type after defaults are applied
Type Parameters
Section titled “Type Parameters”TFieldSlug
Section titled “TFieldSlug”TFieldSlug extends string = ConvexSystemField
TComponent
Section titled “TComponent”TComponent extends ComponentHKT = ComponentHKT
TCollectionSlug
Section titled “TCollectionSlug”TCollectionSlug extends CollectionSlug = CollectionSlug
Properties
Section titled “Properties”components?
Section titled “components?”
optionalcomponents?:object&AdminListComponentsInput
Defined in: packages/core/src/collections/types.ts:376
Collection-level edit.* slot contributions and built-in overrides (decision 11/14) —
merged with the project-wide config of the same shape by resolveEditSlot at render time.
Also carries this collection’s own additive contributions to its own list.* slots
(S17/S18) — create, search, filters, columns, views, and row/bulk delete are built-ins
(vex.list.*) and need no entry here; this is only for custom row/bulk actions and other
project-authored contributions, merged with vex.list.* built-ins by ListViewLayout, never
here.
Deviation from the list-view-overhaul spec’s literal text (reported in Step 9’s digest):
the spec drafted this as a brand-new standalone components?: AdminListComponentsInput
property, not realizing the edit-view overhaul had already landed components?: { edit?: EditComponentsConfigInput<TComponent> } on this same interface — a literal second
components property would be a duplicate-identifier error. The seven list-slot arrays
are merged flat into the existing components object instead (matching the spec’s own
collection.admin.components.rowActions access pattern verbatim, with no extra .list
nesting level to introduce).
Type Declaration
Section titled “Type Declaration”
optionaledit?:EditComponentsConfigInput<TComponent>
optionalicon?:string
Defined in: packages/core/src/collections/types.ts:314
A valid Lucide icon name for this collection in the admin sidebar See https://lucide.dev/icons/
livePreview?
Section titled “livePreview?”
optionallivePreview?:AdminLivePreviewConfigInput<Partial<TDocument>>
Defined in: packages/core/src/collections/types.ts:357
Live preview for this collection — the resolver from a document to the public URL its preview iframe renders, plus panel behaviour. Omit to disable live preview for this collection.
useAsTitle?
Section titled “useAsTitle?”
optionaluseAsTitle?:"_id"|"_creationTime"|"_updatedAt"|NoInfer<TFieldSlug>
Defined in: packages/core/src/collections/types.ts:309
The field whose value is displayed as the document’s human-readable title throughout the admin panel (list rows, breadcrumbs, relation pickers).
Accepts any user-defined field slug from this collection, or a built-in
Convex system field ("_id" | "_creationTime"). Setting a user-defined
field also auto-generates a database index (by_<field>) and a search
index (search_<field>) for fast admin queries. Omit to fall back to "_id".
optionalview?:VexViewState<TFieldSlug>
Defined in: packages/core/src/collections/types.ts:325
The default (“All”) view — the view active whenever the URL carries no
view= param, AND (Decision 45 FINAL) the collection-wide list
settings that used to live on the now-deleted admin.table
(searchFields, pageSizeOptions, countLimit, serverPageSize,
bulkActions) — see VexViewState, the same type admin.views[n]
entries share.
Default
Section titled “Default”{ sort: { field: "_creationTime", order: "desc" }, columns: every non-hidden field, pageSize: 10, searchFields: [], pageSizeOptions: [10, 25, 50, 100], countLimit: 10000, serverPageSize: 100, bulkActions: { delete: true } }views?
Section titled “views?”
optionalviews?:VexViewConfig<TFieldSlug>[]
Defined in: packages/core/src/collections/types.ts:351
Additional preset views, rendered as tabs after the default (“All”)
tab, in declaration order — read-only in the admin panel (Decision
11’s config source). Merged at render time with shared (vex_views)
and local (browser) views by viewId (useSavedListViews, Step 12).
Replaces the former admin.table.views (clean cutover, Decision 45/48).
Every viewId must be unique within this collection (including against
the reserved "default" id), every where must only name this
collection’s own fields (plus "_creationTime"/"vex_status"), every
sort.field must lead a declared index, every searchField must be
declared on admin.view’s own resolved searchFields, and every
columns entry must be a known field — all checked by validateSavedListViewConfig.
Hidden view filters are hidden from the UI, not secret. A view’s
state.where ships in the client bundle like an access rule (P-004,
Decision 25) — don’t encode sensitive thresholds or identifiers in it.
UI code never reads state.where directly; it reads the
VexClientViewConfig projection toClientSavedListViewConfig builds
instead, which replaces where with hasHiddenFilter/hiddenFilterCount.
The ONE other reader of the raw where is composeSavedListViewWhere
(collections/savedListViews/composeSavedListViewWhere.ts), which ANDs it into the where
the client sends — find/search take no view argument.
Default
Section titled “Default”[]