Eventi & Interazioni
Un secondo playground: qui non configuri un componente ma le interazioni tra componenti. Tutto passa da un unico bus (il kernel), su cui Action, reactions e logica dello sviluppatore parlano la stessa lingua.
Playground interattivo
Configura a quale evento reagisce ciascun box e con quale effetto, poi emetti un messaggio: reagiscono solo i box in ascolto di quel messaggio. Guarda il log del bus in fondo.
Emetti un messaggio sul bus
Configura sotto quale box reagisce a quale evento, poi emetti: solo i box in ascolto di quel messaggio reagiscono. È lo stesso bus che collega Action, reactions e logica dev.
Log del bus (ultimi 12)
- — nessun messaggio ancora —
1. Il kernel unificato
UIMS ha due direzioni di eventi: outbound (un componente fa qualcosa —dispatch) e inbound (un componente reagisce — subscribe). Vivono su un solo kernel sul context provider:
dispatch(msg)— comando 1→1 che ritorna un valore.emit(msg)— notifica 1→N (fire-and-forget).subscribe(type, fn)— ascolta un messaggio.use(mw)— middleware del dev (intercetta/trasforma/annulla).registerEffect / runEffect— effetti custom lanciabili da codice.
2. Trigger — quando reagire
Il lato «quando». Vocabolario curato, esteso ma finito:
on:viewportEnter— l'elemento entra nello schermo (scroll). Attivo.on:event(name)— un messaggio del bus. Attivo.- In arrivo:
on:viewportExit,on:mount,on:hover / click,on:media(query),on:route.
3. Effetti — cosa fare
Il lato «cosa». Union taggata per type, dietro un unico do:
animate— swap di classiinitial → ending(fadeIn, slideUp…). Attivo.dispatch— emette un messaggio del bus (con payload). Attivo.state— toggle di stato/classe (in arrivo).run— esegue un effetto custom registrato dal dev.
Gli effetti visivi sono solo classi: il moto (durate/easing) vive nel tema, le classi nella safelist. Dogfooding puro.
4. Il ponte dispatch→emit
Dopo che un dispatch esegue il suo handler, il kernel emette anche lo stesso messaggio agli iscritti. Così una reaction on:event(ui:close) reagisce al comando ui:close senza configurazione extra: producer e consumer si saldano da soli.
Es. nel playground componenti: il bottone «Rivela» fa dispatch(ui:reveal) → la sezione target in ascolto (on:event(ui:reveal)) compare.
5. Payload & token
Ogni messaggio porta un payload opaco (oggetto), definito da admin o da codice, e intercettabile da chi ascolta. I valori-stringa possono usare token risolti a runtime:
{{event.*}}— dal payload del messaggio innescante (pipeline di dati).{{query.*}}— dai query param dell'URL.{{node.*}}— dati/attributi dell'elemento.{{now}}— timestamp.
La logica (calcoli, condizioni) non è compito dei token: resta al middleware del dev.
6. Il dev seam
Lo sviluppatore è pari all'admin sullo stesso kernel:
- Middleware (
use): intercetta ogni messaggio, applica logica proprietaria, può trasformarlo o annullarlo. - Effetto custom (
registerEffect+runEffect): cambia la UI da logica applicativa. - In sviluppo il kernel è su
window.__uimsKernel— prova__uimsKernel.emit({type:"ui:signal-a"})dalla console.
7. Eventi disponibili nel sistema
Messaggi baseline già configurati (selezionabili in admin, riusabili nelle reactions):
ui:close— chiude modali/drawer contenitori.ui:scrollToTop— scorre in cima (BackToTop / primo item Scrollspy).ui:reveal— notifica di rivelazione (demo playground).alertDialog:confirm— conferma asincrona di un AlertDialog (override consumer).demo:ping— evento demo intercettato dal middleware.
Ogni handler registrato dal consumer diventa automaticamente un evento selezionabile: il catalogo è estendibile senza toccare il motore.