Adapters

Adapters guide

Adapters are the thin integration layer between ng-orbit headless controllers and your product UI, and ng-orbit already ships ready-to-install Material and Daisy options for teams that want a faster adoption path.

The contract stays the same: controllers own state and commands, adapters translate that state into UI, and the consumer keeps business logic, data, and forms whether the UI is custom or installed from a renderer package.

    Keep the adapter thin.
Read state from the headless controller.
Call only controller commands from UI events.
Leave data fetching, forms, and side effects to the consumer.

    @ng-orbit/table -> headless table controller
@ng-orbit/wizard -> headless wizard controller
@ng-orbit/notify -> headless notification service
@ng-orbit/wizard-kit -> optional form-sync bridge
@ng-orbit/notify-render-plain -> ready semantic notification renderer
@ng-orbit/table-render-plain -> ready semantic table renderer
@ng-orbit/table-render-material and table-render-daisy -> ready table renderers
@ng-orbit/wizard-render-material and wizard-render-daisy -> ready wizard renderers

Ready to install

These renderer packages are already available today, so consumers can start quickly and still keep the controller contract swappable later.

    pnpm add @ng-orbit/table @ng-orbit/table-render-material

    pnpm add @ng-orbit/table @ng-orbit/table-render-daisy

    pnpm add @ng-orbit/wizard @ng-orbit/wizard-kit @ng-orbit/wizard-render-material

    pnpm add @ng-orbit/wizard @ng-orbit/wizard-kit @ng-orbit/wizard-render-daisy

What adapters mean in ng-orbit

An adapter is the UI-facing layer that reads controller state, maps it into your design system, and sends user intent back through controller commands.

Adapters can be as small as a custom template around exportAs controllers.
Ready-to-install Material and Daisy renderer packages are one adapter flavor already available today.
The headless controller remains the only source of truth for UI state.

When to build one

Build a custom adapter when your product already has opinionated UI primitives, layout rules, analytics hooks, or accessibility patterns that generic renderers should not own.

Use a thin wrapper around your own table, cards, step nav, or footer actions.
Keep the adapter reusable inside your product surface, not inside the core package.
Reach for the ready-to-install Material or Daisy packages when speed matters more than bespoke UI control.

Where kits and renderers fit

Kits help you compose product-owned UI without giving up the contract. Renderers package more UI upfront, but they should still stay presentation-only.

wizard-kit is the current public bridge for form-backed wizard steps.
Table and wizard already have installable Material and Daisy renderer packages.
table-kit and wizard-render-plain still exist only as repo placeholders.
Renderers remain optional and should not fetch data or own submission rules.
The same ownership rules apply whether the adapter is custom, kit-assisted, or full-renderer.

    <section
  orbitTable
  #table="orbitTable"
  [rows]="rows()"
  [columns]="columns"
  [total]="total()"
  [loading]="loading()"
  [error]="error()"
  [query]="query()"
  [getRowId]="getRowId"
  (orbitTableQueryChange)="onQueryChange($event)"
>
  <product-data-grid
    [rows]="table.rows()"
    [loading]="table.loading()"
    [canNextPage]="table.canNextPage()"
    (searchChange)="table.setSearch($event)"
    (sortChange)="table.toggleSort($event.columnId)"
    (pageChange)="table.setPage($event)"
  />
</section>