Il kernel unificato
I comportamenti lato utente passano da un unico kernel sul context provider. Direzione outbound (un componente FA qualcosa: dispatch) e inbound (un componente REAGISCE: subscribe) vivono sullo stesso bus.
API del kernel: dispatch (comando 1→1 che ritorna), emit (notifica 1→N), subscribe (ascolta un messaggio), use (middleware del dev), registerEffect/runEffect (effetti custom lanciabili da codice).
Reattività: trigger → effetto
Sull’ISTANZA di un blocco (non sul viewMode) si definiscono reazioni "quando → fai": un trigger (on:viewportEnter, on:event) e un effetto (una ricetta della collection effects: animate, dispatch).
Gli effetti visivi sono solo classi (initial → ending via una behavior); il moto vive nel tema, le classi nella safelist. Dogfooding puro.
Il ponte dispatch→emit
Dopo che un dispatch esegue il suo handler, il kernel emette anche lo stesso messaggio agli iscritti: una reaction on:event(ui:close) reagisce al comando ui:close senza configurazione extra. Producer e consumer si saldano da soli.
Esempio: BackToTop e il primo item dello Scrollspy dispatchano lo stesso ui:scrollToTop; un handler condiviso riporta in cima.
Payload, token e dev seam
Ogni messaggio porta un payload opaco, intercettabile. I valori-stringa possono usare token risolti a runtime: {{event.*}}, {{query.*}}, {{node.*}}, {{now}}. La logica resta al middleware del dev.
Il dev è pari all’admin sul kernel: middleware (use) per intercettare/trasformare, effetti custom (registerEffect/runEffect) per cambiare la UI da codice. In sviluppo il kernel è su window.__uimsKernel.
Playground
Provalo dal vivo: /playground/eventi intreccia trigger e componenti (emetti messaggi, configura chi reagisce, guarda il log del bus) con una guida esaustiva.
Ogni componente ha inoltre un playground con form di configurazione live in /playground → /components/<slug>.