Overview
Pattern: Framework data + Custom component
Il data layer (recupero dati, filtri, paging, CRUD, permessi) viene dal framework WUIC, ma il rendering UI lo scrivi tu in Angular standard. Si usa <wuic-data-source> per ottenere uno stream reattivo di righe + metadata, e si subscribe a fetchInfo$ per costruire il layout che vuoi (cards, dashboard KPI, kanban, calendario, mappa, ...).
Quando usarlo
- L'entity esiste gia' lato framework (scaffolding fatto) e vuoi riusare CRUD, paging, filtri e permessi.
- L'UX standard (
<wuic-list-grid>) non si adatta al caso d'uso. - Vuoi UI mobile-first o un layout brand-specifico.
- Hai dati gerarchici o aggregati che non entrano in una tabella piatta.
Architettura
Browser Framework data
| |
| <wuic-data-source #ds |
| [hardcodedRoute]="'cities'"> |
| |
| fetchInfo$ (Observable) <-- DataSourceComponent (gestisce CRUD + filtri)
| |Responsabilita':
- DataSource (framework): fetch di dati e metadata, paging, filtri, sync CRUD. Espone
fetchInfo$(Observable),metaInfo, helper comesetCurrent,addNewRecord,syncData. - Componente custom (tuo): subscribe a
fetchInfo$, trasforma le righe in qualunque visualizzazione, chiama i metodi del datasource per scatenare azioni (filtro, edit, refresh).
Snippet chiave
<!-- source: wwwroot/src/app/component/examples/pattern-2/2a-cities-cards/2a-cities-cards.component.html -->
<wuic-data-source #ds [hardcodedRoute]="'cities'" [autoload]="true"></wuic-data-source>
<div class="cards-grid">
@for (city of rows(); track city.cityid) {
<p-card [header]="city.cityname">
<p>{{ city.stateprovincename }}</p>
<p>Popolazione: {{ city.latestrecordedpopulation | number }}</p><!-- source: wwwroot/src/app/component/examples/pattern-2/2a-cities-cards/2a-cities-cards.component.ts -->
import { Component, ViewChild, AfterViewInit, signal } from '@angular/core';
import { CardModule } from 'primeng/card';
import { CommonModule } from '@angular/common';
import { DataSourceComponent } from 'wuic-framework-lib';
@Component({
selector: 'app-cities-cards',Trade-off
| Pro | Contro |
|---|---|
| Sfrutti CRUD, filtri, paging, permessi e audit del framework | Devi scrivere e manutenere la UI |
| UX completamente libera | Devi rispettare il contratto fetchInfo$ |
| Cambi solo UI senza toccare backend | Costo di sviluppo piu' alto del Pattern 1 |
| Tutti gli eventi CRUD restano hookable lato server | Devi conoscere le API client del framework (DataSourceComponent, MetaInfo) |
Esempi vivi nel WuicTest
- Cities cards → data source su
cities+ grid p-card responsive con filtro client. Cartella sorgente:wwwroot/src/app/component/examples/pattern-2/2a-cities-cards/. Apri demo. - Cities KPI dashboard → stesso datasource, aggregazioni client-side (count, top-N, group-by stato) in p-card. Cartella sorgente:
wwwroot/src/app/component/examples/pattern-2/2b-cities-kpi-dashboard/. Apri demo. - Custom cities list → wrappa
<app-custom-list>(componente Angular reusabileIDataBoundHostComponent) su<wuic-data-source>+<wuic-filter-bar>+<wuic-pager>. Dimostra come un renderer custom riusabile si aggancia al data layer WUIC. Cartella sorgente:wwwroot/src/app/component/examples/pattern-2/2c-custom-cities-list/. Apri demo.
Vedi anche
- Pattern 1 — Full autogeneration: se l'UX standard basta.
- Pattern 3 — Framework component + Custom data: inverso (UI WUIC, dati custom).
- Pattern 4 — Full custom: pure Angular + backend tuo, niente componenti ne' data layer del framework.
- Pattern 5 — Framework component + Framework data (manual mount): stessa data layer del Pattern 2 ma UI composta da widget WUIC anziche' da componenti custom.
- Designer & Workflow: per personalizzare l'UX senza uscire dal pattern 1.