resolveListViewQueryState
resolveListViewQueryState<
TFieldSlug>(props):ResolvedListViewQueryState<TFieldSlug>
Defined in: packages/core/src/collections/listView/listViewQueryState.ts:165
Resolves one list query’s effective state by merging three layers, narrowest first: the
parsed URL (params, Design Decision 40’s codec), the active view’s own saved state
(configView/sharedView, whichever the caller resolved params.view to — or, when
neither resolves and params.view is unset, the collection’s own resolved default
(“All”) view, collection.admin.view, Decision 45/48), and that same default view as the
terminal fallback below an incomplete shared/local view.
This merge is what makes a bare ?view=shared:<id> link — unmodified from the saved
view, so serializeListViewUrlState wrote none of its matching params (Design Decision 9:
“only params that differ from the saved view appear”) — render the SAME rows as the
view’s own tab: without it, an omitted sort/filter would silently fall back to the
collection default instead of the view’s. A local view never reaches here with
configView/sharedView set — its full state is always in the URL already (Design
Decision 41), so params alone is already complete for it, and params.view being set
(to a local:… value) keeps this function from ALSO substituting the default view.
Called by NextAdminPage (server prerender, Design Decision 39, this step) and by
CollectionListView (client, Steps 9/10/12) before either builds its query args — the
ONE place this merge lives, so a link to an unmodified view can’t render different rows
on the two sides (layout-stability.md).
Decision 7 (polish fix): sort/searchField are validated against the live
collection before being returned — a stale value (the field no longer exists, or
leads no declared index/isn’t in searchFields) falls back to the collection
default’s own value for that part ONLY, and the fallback is reported via
staleSortField/staleSearchField so the caller can show a dismissible notice.
Same shape for a USER-added filter condition naming an unreadable field
(access-system-fields.md Decision 11) — dropped, reported via
staleFilterField, when props.fieldPermissions is supplied.
The saved view/URL itself is never rewritten.
Type Parameters
Section titled “Type Parameters”TFieldSlug
Section titled “TFieldSlug”TFieldSlug extends string = string
Parameters
Section titled “Parameters”Input props.
collection
Section titled “collection”The resolved collection config — supplies
admin.view, the resolved default (“All”) view (sort/columns/
pageSize always present, where/searchField optional), both as the
ACTIVE view when nothing else is and as the terminal fallback beneath
an incomplete shared/config view.
configView?
Section titled “configView?”VexViewConfig<TFieldSlug>
fieldPermissions?
Section titled “fieldPermissions?”The caller’s resolved field-read permissions
(resolveFieldPermissions/useFieldPermissions). undefined (the
default) skips the unreadable-filter-field drop entirely — matches the
old unguarded behavior for a caller that hasn’t been updated to supply it.
params
Section titled “params”ListViewUrlState<TFieldSlug>
sharedView?
Section titled “sharedView?”VexStoredView<TFieldSlug>
The shared-source view params.view names, from the
fetched/cached listViews result — undefined for any other source.
Returns
Section titled “Returns”ResolvedListViewQueryState<TFieldSlug>
The resolved state.