Merge branch 'main' into claude/issue-8347-baseschema-index-signature

Author: os-zhuang

.changeset/11605-i18n-view-no-object.md

@@ -0,0 +1,12 @@
+---
+'@object-ui/i18n': minor
+---
+
+All ten locale packs gain `view.noObject`, the hint an object-bound block shows
+when its node names its object in neither place (objectui#11605).
+
+**Clause-②: yes (widening)** — a new key, `view.noObject`, in every pack. English
+reads "No object named: set {{property}} or dataSource.object.", the wording of
+`element.number.noObject` with the property as a hole; each translation is that
+key's own translation with the same hole. `{{property}}` is the block's object
+key, interpolated and never translated. No existing key changes.

.changeset/11605-plugin-charts-objectname-optional.md

@@ -0,0 +1,24 @@
+---
+'@object-ui/plugin-charts': minor
+---
+
+The `object-chart` and `view:chart` registrations no longer declare `objectName`
+required, so the page compile accepts a node whose `dataSource` binding names the
+object, and a chart that names its object in neither place shows a hint instead
+of an empty frame (objectui#11605).
+
+`object-chart` has no spec row. The binding doc says a node bound by
+`dataSource.object` needs no `objectName` of its own, and the renderer agrees:
+`dataSource.object` lands on `objectName` before the chart reads the node. The
+registrations still declared `required: true`, and the page compile reads them,
+so a bound chart with no `objectName` of its own was refused with
+`missing-required-prop` and the save failed.
+
+**Clause-②: yes (widening)** — an `object-chart` (or `view:chart`) node that
+names its object through `dataSource.object` and sets no `objectName` now
+compiles and saves. A node that names its object in neither place also compiles
+now, and the chart shows "No object named: set objectName or dataSource.object."
+where it used to draw an empty frame with no message. A chart with inline
+`data`, a `dataset` or a `bind` path shows no hint and renders as before. The
+published `objectName` inputs now carry a description that says the binding can
+supply them.

.changeset/11605-plugin-dashboard-objectname-optional.md

@@ -0,0 +1,27 @@
+---
+'@object-ui/plugin-dashboard': minor
+---
+
+The `object-metric` and `object-pivot` registrations no longer declare
+`objectName` required, so the page compile accepts a node whose `dataSource`
+binding names the object, and a node that names its object in neither place
+shows a hint instead of a value or an empty table (objectui#11605).
+
+`@objectstack/spec`'s `object-metric` row leaves `objectName` optional, because
+the node's `dataSource` binding can supply it; `object-pivot` has no spec row,
+and the binding doc says a bound node needs no `objectName` of its own. Both
+renderers agree: `dataSource.object` lands on `objectName` before the block
+reads the node. The registrations still declared `required: true`, and the page
+compile reads them, so a bound node with no `objectName` of its own was refused
+with `missing-required-prop` and the save failed.
+
+**Clause-②: yes (widening)** — an `object-metric` or `object-pivot` node that
+names its object through `dataSource.object` and sets no `objectName` now
+compiles and saves. A node that names its object in neither place also compiles
+now, and shows "No object named: set objectName or dataSource.object." where the
+metric used to draw a bare dash and the pivot an empty state saying its query
+returned no records. A metric with an authored `fallbackValue`, and a pivot with
+inline `data` or a `bind` path, show no hint and render as before.
+`object-data-table` is unchanged: it reads no binding, so its `objectName` stays
+required. The published `objectName` inputs now carry a description that says
+the binding can supply them.

.changeset/11605-plugin-form-objectname-optional.md

@@ -0,0 +1,31 @@
+---
+'@object-ui/plugin-form': minor
+---
+
+The `object-form`, `view:form`, `embeddable-form` and
+`object-master-detail-form` registrations no longer declare `objectName`
+required, so the page compile accepts a node whose `dataSource` binding names the
+object, and a form that names its object in neither place shows a hint instead of
+a form with no fields (objectui#11605).
+
+`@objectstack/spec`'s `object-form` and `object-master-detail-form` rows leave
+`objectName` optional, because the node's `dataSource` binding can supply it;
+`embeddable-form` has no spec row, and the binding doc says a bound node needs no
+`objectName` of its own. Each renderer agrees: `dataSource.object` lands on
+`objectName` before the form reads the node. The registrations still declared
+`required: true`, and the page compile reads them, so a bound form with no
+`objectName` of its own was refused with `missing-required-prop` and the save
+failed.
+
+**Clause-②: yes (widening)** — an `object-form`, `view:form`, `embeddable-form`
+or `object-master-detail-form` node that names its object through
+`dataSource.object` and sets no `objectName` now compiles and saves. A node that
+names its object in neither place also compiles now, and shows "No object named:
+set objectName or dataSource.object." where it used to draw a field-less card, a
+public form that could not submit, or an empty parent form. An `object-form`
+or `view:form` whose fields are declared inline shows no hint and renders as
+before: non-empty `customFields`, or `sections` whose every field is an inline
+field, the target-less collector the `tabbed`, `wizard`, `split`, `drawer` and
+`modal` variants render. `formId` on `embeddable-form` and `details` on
+`object-master-detail-form` are still required. The published `objectName`
+inputs now carry a description that says the binding can supply them.

.changeset/11605-plugin-grid-objectname-optional.md

@@ -0,0 +1,21 @@
+---
+'@object-ui/plugin-grid': minor
+---
+
+The `object-grid` and `view:grid` registrations no longer declare `objectName`
+required, so the page compile accepts a node whose `dataSource` binding names the
+object (objectui#11605).
+
+`@objectstack/spec`'s `object-grid` row leaves `objectName` optional, because the
+node's `dataSource` binding can supply it, and the renderer agrees:
+`dataSource.object` lands on `objectName` before the grid reads the node. The
+registration still declared `required: true`, and the page compile reads the
+registration, so a bound node with no `objectName` of its own was refused with
+`missing-required-prop` and the save failed.
+
+**Clause-②: yes (widening)** — an `object-grid` (or `view:grid`) node that names
+its object through `dataSource.object` and sets no `objectName` now compiles and
+saves. A node that names its object in neither place also compiles now; the grid
+answers it at runtime with its own "Object name required for data fetching"
+error, as it did before when such a node reached it. The published `objectName`
+input now carries a description that says the binding can supply it.

.changeset/11605-plugin-kanban-objectname-optional.md

@@ -0,0 +1,24 @@
+---
+'@object-ui/plugin-kanban': minor
+---
+
+The `object-kanban` registration no longer declares `objectName` required, so
+the page compile accepts a board whose `dataSource` binding names the object, and
+a board that names its object in neither place shows a hint instead of an empty
+board (objectui#11605).
+
+`@objectstack/spec`'s `object-kanban` row leaves `objectName` optional, because
+the node's `dataSource` binding can supply it, and the renderer agrees:
+`dataSource.object` lands on `objectName` before the board reads the node. The
+registration still declared `required: true`, and the page compile reads the
+registration, so a bound board with no `objectName` of its own was refused with
+`missing-required-prop` and the save failed.
+
+**Clause-②: yes (widening)** — an `object-kanban` node that names its object
+through `dataSource.object` and sets no `objectName` now compiles and saves. A
+node that names its object in neither place also compiles now, and the board
+shows "No object named: set objectName or dataSource.object." where it used to
+draw an empty board reading "No cards". A board with rows from inline `data`
+(an empty array included), a `bind` path or a parent view shows no hint and
+renders as before. The published `objectName` input now carries a description
+that says the binding can supply it.

.changeset/11605-plugin-list-objectname-optional.md

@@ -0,0 +1,24 @@
+---
+'@object-ui/plugin-list': minor
+---
+
+The `list-view` and `view:list` registrations no longer declare `objectName`
+required, so the page compile accepts a node whose `dataSource` binding names the
+object, and a list that names its object in neither place shows a hint instead of
+an empty list (objectui#11605).
+
+`list-view` has no spec row. The binding doc says a node bound by
+`dataSource.object` needs no `objectName` of its own, and the schema validator
+counts the binding as a `list-view` record source. The renderer agrees:
+`dataSource.object` lands on `objectName` before the list reads the node. The
+registrations still declared `required: true`, and the page compile reads them,
+so a bound list with no `objectName` of its own was refused with
+`missing-required-prop` and the save failed.
+
+**Clause-②: yes (widening)** — a `list-view` (or `view:list`) node that names its
+object through `dataSource.object` and sets no `objectName` now compiles and
+saves. A node that names its object in neither place also compiles now, and the
+list shows "No object named: set objectName or dataSource.object." where it used
+to draw the "Nothing here yet" empty state. A list with inline `data` shows no
+hint and renders as before. The published `objectName` input now carries a
+description that says the binding can supply it.

.changeset/11605-react-requires-object.md

@@ -0,0 +1,24 @@
+---
+'@object-ui/react': minor
+---
+
+`ElementDataSourceGate` takes a `requiresObject` prop: when a placement opts in
+and its node names its object in neither place, the gate renders a short "no
+object named" hint instead of the block (objectui#11605).
+
+The object-bound registrations stopped declaring their object key required,
+because the `dataSource` binding can supply it and the page compile has no "this
+key or that binding" form. So the page compile accepts a node that names no
+object at all, and the runtime's answer is the only signal left for it. Several
+blocks answered such a node with an empty list, board, form, chart, dash or pivot,
+which reads as an empty query.
+
+**Clause-②: yes (widening)** — `ElementDataSourceGateProps` gains the optional
+`requiresObject` boolean. With it set, the gate reads the mapping's object key
+(`objectName` unless the mapping names another) on the node after the binding
+lands, so a node bound by `dataSource.object` renders as before; a node that names
+no object gets the hint, "No object named: set objectName or dataSource.object."
+(`data-testid` `{testId}-no-object`), and the block is not mounted. Without the
+prop, or with a mapping whose `object` is `false`, nothing changes. The hint is
+drawn after the view states, so a binding that is still resolving or failed to
+resolve keeps its own panel.