Found while executing objectui#7779 (PR #7922) on origin/main 6a9ee323; out of that card's scope (a docs page, and listViews stays ledgered there), so filed on its own. Filed by the dev of session_01BAZFhALsQsGqxui8sNqM8s's dispatch.
What is wrong
content/docs/api/schema-reference.md, the ObjectViewSchema example (the listViews block around line 855): the my-deals entry carries "default": true.
NamedListView (packages/types/src/objectql.ts:1957–:2134, about 52 members) declares no default member.- The
object-view node renderer picks the opening view from the NODE-level ObjectViewSchema.defaultListView (packages/plugin-view/src/ObjectView.tsx:701, if (schema.defaultListView && namedListViews?.[schema.defaultListView])) and otherwise the first key; nothing reads an entry-level flag. The renderer's read set off a named view is label, type, columns, filter, sort, options, data (derived off disk in packages/types/src/__tests__/object-view-unmirrored-keys-7779.test.ts).
BaseSchema is passthrough, so the example validates green and the flag does nothing; the same example omits defaultListView, so the view it labels as default never opens first.
A second dialect on the same page
The same example writes "filter": [["owner", "=", "..."]] — the ObjectQL tuple form — while packages/plugin-view/README.md and content/docs/plugins/plugin-view.mdx teach filter: [{ field, operator, value }] objects for the same key. NamedListView.filter is typed as an untyped array, so both validate; which of the two mergeFilterNodes actually runs was not measured here. Two dialects taught for one key is the objectui#2890 class.
Expected
The example spells defaultListView: "my-deals" and drops default; the filter dialect on this page is unified with the plugin-view pages once the running shape is measured. A doc-fixture pin against NamedListView's declared members would keep an undeclared key from being taught again.
Refs: objectui#7779 · PR #7922 · objectui#2890 (the ObjectView audit)
Found while executing objectui#7779 (PR #7922) on
origin/main6a9ee323; out of that card's scope (a docs page, andlistViewsstays ledgered there), so filed on its own. Filed by the dev ofsession_01BAZFhALsQsGqxui8sNqM8s's dispatch.What is wrong
content/docs/api/schema-reference.md, theObjectViewSchemaexample (thelistViewsblock around line 855): themy-dealsentry carries"default": true.NamedListView(packages/types/src/objectql.ts:1957–:2134, about 52 members) declares nodefaultmember.object-viewnode renderer picks the opening view from the NODE-levelObjectViewSchema.defaultListView(packages/plugin-view/src/ObjectView.tsx:701,if (schema.defaultListView && namedListViews?.[schema.defaultListView])) and otherwise the first key; nothing reads an entry-level flag. The renderer's read set off a named view islabel,type,columns,filter,sort,options,data(derived off disk inpackages/types/src/__tests__/object-view-unmirrored-keys-7779.test.ts).BaseSchemais passthrough, so the example validates green and the flag does nothing; the same example omitsdefaultListView, so the view it labels as default never opens first.A second dialect on the same page
The same example writes
"filter": [["owner", "=", "..."]]— the ObjectQL tuple form — whilepackages/plugin-view/README.mdandcontent/docs/plugins/plugin-view.mdxteachfilter: [{ field, operator, value }]objects for the same key.NamedListView.filteris typed as an untyped array, so both validate; which of the twomergeFilterNodesactually runs was not measured here. Two dialects taught for one key is the objectui#2890 class.Expected
The example spells
defaultListView: "my-deals"and dropsdefault; the filter dialect on this page is unified with the plugin-view pages once the running shape is measured. A doc-fixture pin againstNamedListView's declared members would keep an undeclared key from being taught again.Refs: objectui#7779 · PR #7922 · objectui#2890 (the ObjectView audit)