API service reference
NgxViewBuilderApiService is the one service your application talks to. Inject it anywhere, in a page component, a resolver, a service of your own, and use it to read and change the view on screen, react to what happens in it, and plug your own functions, validators, elements and icons in.
import { inject } from '@angular/core';
import { NgxViewBuilderApiService } from '@ngxviewbuilder/runtime';
export class ClientPage {
private readonly api = inject(NgxViewBuilderApiService);
async save(): Promise<void> {
const result = await this.api.validateData();
if (result.isValid) {
await this.clients.save(this.api.getData());
}
}
}An application that hosts the builder imports the same service from @ngxviewbuilder/designer. It is the same class.
How a call reaches the view
You always inject the root service. What it talks to depends on what is on screen:
| On screen | Calls about the view (values, structure, elements, validation) go to | Registrations (functions, validators, elements, icons, theme) go to |
|---|---|---|
<ngx-view-builder-runtime> | that runtime view | the root and every runtime view, now and later |
| several runtime views | the one created last | the root and every runtime view |
<nvb-scope> | the scope | the root and every scope |
<ngx-view-builder-designer> | the view being edited (the builder owns it) | the root, the builder and its Preview |
| nothing yet | the root itself | the root; views created later pick them up |
Two things follow from that table. You can register everything at startup, before any view exists, and every view gets it. And you never need a reference to a particular runtime, because the root forwards. When several views render at once, every event still reaches the root and carries elementName and elementDataPath, which is how you tell them apart.
Waiting for a view
Values and elements exist once the view has rendered. Subscribe to onAfterRender, or call the API from a button or an event handler, rather than straight from your constructor.
Reading this reference
Each page groups the methods of one area. Every method shows its signature, what it does, an example, and what it returns. Types are written in TypeScript; IStructure is the view JSON described in Structure JSON.
| Page | What it covers |
|---|---|
| Structure & settings | Read, replace and patch the view definition and its settings |
| Data & values | Form data, single values, server errors, the dirty flag |
| Elements | Finding elements, reading and writing their properties, the element handle, rows of repeaters, element defaults |
| Validation & lifecycle | Validating the view or any structure, toasts, render and completion notifications |
| Data sources & variables | Reloading sources, host sources, websocket authorization, runtime variables and external context |
| Language & theme | Language, locale, translations, UI dictionaries, theme modes, tokens and custom CSS |
| Extensions | Expression functions, validator types, custom elements and properties, icons, table cells |
| Builder, templates & tables | Template library, element library, table settings and filters, builder tabs |
Events have their own page: Events reference.