@praxisui/core 9.0.35 → 9.0.37
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +31 -1
- package/ai/component-registry.json +753 -22
- package/fesm2022/praxisui-core.mjs +2163 -481
- package/package.json +1 -1
- package/types/praxisui-core.d.ts +126 -5
package/README.md
CHANGED
|
@@ -161,6 +161,12 @@ registry.register(metadata);
|
|
|
161
161
|
|
|
162
162
|
Component-owned config editors, AI authoring manifests, and runtime profiles are declared on `ComponentDocMeta`. A runtime profile describes the input constraints and concrete effects of one audited configuration shape; it does not authorize those effects. Hosts must evaluate the profile and grant capabilities independently, bound to the exact document being executed, instead of duplicating component behavior in a host-specific allowlist.
|
|
163
163
|
|
|
164
|
+
### Composition validation against a target registry
|
|
165
|
+
|
|
166
|
+
`CompositionValidatorService` is the public canonical validator for executable page composition. `validatePage(page, { registry, links })` verifies every page widget against the supplied target registry, rejects metadata without a materializable Angular component type, resolves top-level and nested ports, and then applies the existing direction, state, Json Logic, transform, semantic-compatibility and feedback-cycle checks. It returns canonical `DiagnosticRecord[]`; consumers must preserve those codes, subjects, paths and blocking flags rather than translating them into a second diagnostics model.
|
|
167
|
+
|
|
168
|
+
The validator performs no rendering, dispatch, HTTP call or persistence. Pass the same `ComponentMetadataRegistry` that the target host uses for dynamic materialization. Registry presence is the materializability evidence supported by the current contract; component packages remain responsible for publishing and testing their own metadata providers.
|
|
169
|
+
|
|
164
170
|
## Dynamic Page Runtime
|
|
165
171
|
|
|
166
172
|
`DynamicWidgetPageComponent` renders `WidgetPageDefinition` documents.
|
|
@@ -206,6 +212,28 @@ those descriptors only in its render projection, so the authored and persisted
|
|
|
206
212
|
document keeps stable semantic keys. Plain strings remain untouched, and
|
|
207
213
|
framework chrome continues to come from each library's i18n catalog.
|
|
208
214
|
|
|
215
|
+
### Composition link delivery and failures
|
|
216
|
+
|
|
217
|
+
Composition links execute in their persisted array order inside one synchronous
|
|
218
|
+
dispatch cycle. `policy.delivery` may be omitted or set to `sync`; the former
|
|
219
|
+
`microtask` and `batched` values were removed during the version 9 beta because
|
|
220
|
+
the dynamic-page cycle has no lifecycle-aware asynchronous continuation or
|
|
221
|
+
batch boundary. Canonical ingress rejects those removed values instead of
|
|
222
|
+
silently treating them as synchronous.
|
|
223
|
+
|
|
224
|
+
`policy.errorPolicy` governs runtime condition, transform and delivery failures:
|
|
225
|
+
|
|
226
|
+
- `diagnostic` (the default) keeps the structured failure evidence and allows
|
|
227
|
+
independent links to continue;
|
|
228
|
+
- `drop` discards only the failed delivery, records
|
|
229
|
+
`RUNTIME_LINK_ERROR_DROPPED`, and does not count the value as delivered;
|
|
230
|
+
- `halt-page` records a fatal diagnostic, stops subsequent effects, and blocks
|
|
231
|
+
dispatch until the page receives a new bootstrap.
|
|
232
|
+
|
|
233
|
+
These policies never downgrade catalog, schema, semantic-validation, or
|
|
234
|
+
bootstrap failures. They also do not catch arbitrary Angular exceptions or
|
|
235
|
+
promise failures produced after a host/global-action adapter accepts a delivery.
|
|
236
|
+
|
|
209
237
|
## Resource Discovery
|
|
210
238
|
|
|
211
239
|
`resourcePath` and `resourceKey` serve different purposes:
|
|
@@ -224,6 +252,8 @@ it must not infer authorization from a `canonicalOperations` boolean or discard
|
|
|
224
252
|
|
|
225
253
|
When a discovered item surface publishes `relatedResource`, `ResourceSurfaceOpenAdapterService` delegates to `RelatedResourceSurfaceResolverService`. The resulting table targets the canonical child resource and receives the parent identity through `queryContext.filters`; it does not prefetch the item projection and rebuild a host-local table before opening. When the child surface publishes `childParentField`, related create actions seed that field through `actions[].form.initialValue`, and both create/update command policies project it into `groupedCommand.contextFields`. The field therefore remains in the schema-backed form and submit payload without rendering a redundant lookup for context the dossier already established. The generated related-resource empty state is informational: CREATE remains the stable, capability-governed toolbar action instead of being duplicated inside the empty state. An explicit host `emptyState.actions` declaration is preserved when the product journey intentionally needs a different contextual action. The materializer declares `openMode: "drawer"` but does not redefine drawer geometry: positioning, viewport height, focus, and close behavior remain owned by `@praxisui/crud`. This keeps the drawer responsive and preserves child operations, empty states, endpoint routing, and resource identity from the backend contract.
|
|
226
254
|
|
|
255
|
+
The outlet's `ComponentDocMeta.configEditor` intentionally owns presentation only: `title`, `subtitle`, `icon`, `mode`, `presentation`, `compact`, and the closed copy/layout subset of `emptyState`. Opening it does not resolve runtime/materialized inputs. Apply and Save preserve every other persisted input opaquely, including Table-owned `tableConfig` and behavior-bearing empty-state fields. The relationship path, parent field/id, operation, filters, query context, surface and runtime state remain metadata/runtime-owned and cannot be authored by this editor or its AI manifest.
|
|
256
|
+
|
|
227
257
|
## Schema And Metadata
|
|
228
258
|
|
|
229
259
|
Core exports schema and metadata infrastructure used by form, table, list, chart, CRUD, and page-builder packages:
|
|
@@ -286,7 +316,7 @@ Core also exports shared AI authoring types, capability types, dynamic-page cont
|
|
|
286
316
|
|
|
287
317
|
`DynamicWidgetPageComponent` treats the editor declared by `ComponentDocMeta.configEditor` as the canonical authoring surface for the **Configurar conteúdo** action. When the Settings Panel bridge is available, the host resolves any transient `contextResolver` evidence and opens that metadata-owned editor even if the live widget also exposes an internal settings shortcut. This keeps the action deterministic across widget loading states.
|
|
288
318
|
|
|
289
|
-
Widget-local settings dispatch remains only a fallback when the canonical Settings Panel/editor is unavailable.
|
|
319
|
+
Widget-local settings dispatch remains only a fallback when the canonical Settings Panel/editor is unavailable. `ComponentConfigEditorContextRequest.persistedInputs` is cloned exclusively from `widget.definition.inputs`. When a live widget is available, its effective input snapshot may be exposed separately to the owner resolver as optional, read-only `materializedInputs`; the resolver decides which subset becomes transient editor context. Opening the editor never applies that snapshot to the page. Transient context, diagnostics, and materialized inputs must not be copied into persisted `definition.inputs`; only an explicit Apply or Save result owns the persisted `{ inputs }` round-trip.
|
|
290
320
|
|
|
291
321
|
## Domain Governance
|
|
292
322
|
|