CollectionListViewProps
Defined in: packages/core/src/framework.ts:85
Props passed to the CollectionListView component.
TCollectionSlug narrows to a literal collection slug when the caller
supplies one; every real caller in this codebase passes a runtime string
(from a URL segment or a config lookup), so it resolves to the full
CollectionSlug union in practice.
Type Parameters
Section titled “Type Parameters”TCollectionSlug
Section titled “TCollectionSlug”TCollectionSlug extends CollectionSlug = CollectionSlug
Properties
Section titled “Properties”collection
Section titled “collection”collection:
TCollectionSlug
Defined in: packages/core/src/framework.ts:87
The slug of the collection being listed, resolved from useVexConfig().
initialFilterValueTitles?
Section titled “initialFilterValueTitles?”
optionalinitialFilterValueTitles?:Record<string,string|null>
Defined in: packages/core/src/framework.ts:134
Server-resolved titles for every relationship/upload id the ACTIVE
filter names (Decision 50) — NextAdminPage walks resolved.where
via collectListViewFilterRelationshipValues, fetches each distinct target
document, and reduces to { [id]: doc[useAsTitle] ?? doc._id }
(null for not-found/denied, degrade-never-crash per Decision 9/32).
Seeds ListViewContext’s own filterValueTitles so a
relationship/upload filter chip/row shows the target’s TITLE, not its
raw id, on the very first paint — no flash from id to title once the
client’s own picker-driven lookups would otherwise resolve it later.
undefined/missing entries fall back to the raw id (never a blocking
state).
initialLocalIndex?
Section titled “initialLocalIndex?”
optionalinitialLocalIndex?:LocalSavedListViewsIndexEntry[]
Defined in: packages/core/src/framework.ts:102
The consolidated vex-admin:<collection> cookie’s localViews field
(Decision 41/51), read server-side by NextAdminPage (Step 14) —
renders a local view’s tab on first paint before localStorage
hydrates it. Omit when rendering client-side only.
initialPreferences?
Section titled “initialPreferences?”
optionalinitialPreferences?:ListViewConfigCookieValues
Defined in: packages/core/src/framework.ts:95
Layout-affecting list preferences resolved server-side from cookies
(parseListViewConfigCookies, Decision 42) — density today, extended by
later steps. Seeds CollectionListView’s own state so the row height
the server rendered and the client’s first paint agree. Omit when
rendering client-side only (falls back to "comfortable").
initialSkeletonDone?
Section titled “initialSkeletonDone?”
optionalinitialSkeletonDone?:boolean
Defined in: packages/core/src/framework.ts:120
The SAME cookie entry’s done flag (zero-footer-shift fix, developer decision) — whether
the active view’s last settled result showed “That’s everything” (true) or a Load More
Button (false). DataTable’s own isPending skeleton footer renders the MATCHING
variant instead of always reserving the taller Button’s height. undefined (no cookie
entry yet) falls back to the Button variant (the prior, safer-default behavior).
initialSkeletonRowCount?
Section titled “initialSkeletonRowCount?”
optionalinitialSkeletonRowCount?:number
Defined in: packages/core/src/framework.ts:112
The consolidated vex-admin:<collection> cookie’s rowCounts field for the active view
(Decision 49 follow-up/51, developer decision), read server-side by NextAdminPage — the
<Suspense> loading-skeleton fallback (CollectionListView.tsx) renders exactly this many
skeleton rows instead of a fixed pageSize guess, matching the row count this view’s
result last actually settled with. undefined (no cookie entry for this view yet) falls
back to pageSize; 0 renders no skeleton rows and no footer, matching the settled empty
state’s own shape as closely as a data-free skeleton can.