Custom Angular Component Creator

Author or edit a Datex Studio Custom Angular Component (CAC, configurationTypeId: 36) on a branch. A CAC is an author-written standalone Angular component — you write the actual component.ts / .html / .scss, not a declarative JSON config. It runs inside the generated app with the real platform context ($datasources, $flows, $shell, …) injected, so it's the escape hatch for UI the declarative components (grid / form / hub / selector / editor) can't express: bespoke charts, dashboards, visualizations, custom layouts.

A CAC can also embed an existing app configuration in its template — declare it as a component reference (selectors first; the contract is generic over component kind) and codegen imports the generated component into the CAC's scope, so a real generated control (e.g. a selector dropdown) renders inside your custom UI.

Clues for embedding: a selector generates in two variants — _single and _multi — so a referenced selector gives you both a single- and a multi-select control to choose from. An embedded control exposes the configuration's own properties as component inputs/outputs (e.g. a selector surfaces each of its datasource parameters as an input named by the parameter id, plus its selected value and a display-text output). To find the exact tag and the inputs/outputs a referenced config exposes, read its generated component in the materialized harness — the @Component selector is the tag to use, and the @Input/@Output members are what you bind — rather than guessing them.

This skill uses a different CLI surface from every other creator. There is no dxs configuration upsert customangularcomponent hand-authoring path here — CAC authoring goes through the dxs ng command family, which materializes a light harness (the one component + real typed context + stub services, generated by the server for the branch), lets you edit the two author regions locally, and renders a screenshot each iteration. Nothing is created in Studio until dxs ng push.

Data pattern (fixed default — never ask)

Whenever a CAC displays data, that data comes from a real, typed datasource — and how it is wired is not a question to put to the user. Do not ask whether to use real data, sample data, an @Input, or how to source it: the pattern is fixed for every component.

• Authoring loop (CLI / dxs ng preview): the component reads through the typed this.$datasources.<ref> stub, but the preview is served mocked data — dxs ng data generate seeds mocks/harness-mocks.json and you fill it with representative values (from a real dxs query). The authoring preview never hits real data.
• After push (generated Studio app): the same typed $datasources.<ref> calls hit the real datasource / real data in the running app. The component always depends on the datasource at runtime.
• Datasource missing on the branch? Create one that matches the real schema with datasource-creator (explore with schema-explorer first) and upsert it before materializing the harness, so the harness types the stub. Never fall back to embedded sample rows in the body or a cast ($datasources as any).

In one line: real typed datasource + mocked data for authoring, real data after push — applied to every CAC without asking. Sample data lives only in mocks/harness-mocks.json (transient, never pushed); the body stays clean with real empty/loading/error states. See Phase 3 for the mechanics.