Progetta macchine a stati finiti (FSM) con un editor visuale. Aggiungi stati e transizioni, simula il comportamento evento per evento, esporta in XState, Mermaid o JSON.
Una macchina a stati finiti è un modello computazionale che descrive il comportamento di un sistema attraverso un insieme finito di stati, transizioni tra stati e eventi che le innescano. In ogni momento il sistema si trova in esattamente uno stato. Esempi reali: un semaforo (rosso → verde → giallo → rosso), un form di checkout (idle → filling → submitting → success/error), un lettore audio (stopped → playing → paused → stopped). Le FSM rendono impossibili stati contraddittori come isLoading && isSuccess.
Inizia elencando tutti gli stati possibili — non solo quelli "felici" ma anche errori, stati intermedi e timeout. Poi identifica gli eventi che causano transizioni. Regola generale: se ti trovi a gestire più di 3 flag booleani correlati (isLoading, isError, isEmpty), stai probabilmente gestendo stati impliciti — una FSM li rende espliciti ed elimina combinazioni impossibili. Aggiorna il diagramma nel tool: aggiungi stati, connetti le frecce con gli eventi, esporta il codice quando la logica è corretta.
useState/useReducer è sufficiente per stati semplici con 2-3 valori indipendenti. FSM con XState è ideale per flussi con più stati mutuamente esclusivi, transizioni condizionali e side effect associati agli stati (es. fetch al cambio di stato). Redux gestisce stato globale condiviso tra molti componenti — non è un sostituto delle FSM, si usano insieme. Zustand/Jotai sono alternative più leggere a Redux per stato globale semplice.
XState è la libreria più usata per implementare state machine in JavaScript e TypeScript. Supporta sia FSM semplici che statechart (stati annidati, paralleli, history). Il codice esportato da questo tool è compatibile con XState v5 — la versione attuale con API più pulita rispetto a v4. Per React esiste @xstate/react con hook dedicati. Per framework diversi da React esiste @xstate/vue, @xstate/svelte e un core framework-agnostico.
I problemi più frequenti: stati impliciti con flag multipli — isLoading && !isError && !isEmpty nasconde stati impossibili come isLoading && isSuccess allo stesso tempo; dimenticare gli stati di errore — ogni operazione asincrona ha almeno 3 stati (loading, success, error); transizioni mancanti — cosa succede se arriva un evento in uno stato inatteso? Una FSM ben progettata gestisce esplicitamente tutti i casi, anche quelli che non dovrebbero mai accadere.
Le FSM non sono necessarie per: toggle semplici on/off (due stati — useBoolean è sufficiente); dati derivati calcolabili da altri valori senza transizioni; form con validazione senza flusso multi-step; contatori e accumulatori che cambiano incrementalmente. Il vero valore delle FSM emerge quando il sistema ha 4+ stati con regole precise su quale transizione è ammessa in quale stato.
Una FSM ha stati piatti (flat) — tutti allo stesso livello. Uno statechart (Harel statechart, usato da XState) aggiunge gerarchie di stati annidati, stati paralleli (più stati attivi simultaneamente in regioni separate) e history states (ricordarsi in quale sotto-stato ci si trovava prima di uscire). Per la maggior parte dei casi d'uso una FSM piatta è sufficiente.
Sì. L'export Mermaid genera codice compatibile con GitHub Markdown, Notion, Confluence e qualsiasi tool che supporti il rendering Mermaid. Incolla il blocco ```mermaid direttamente nel README o nella wiki del progetto per documentazione che rimane sempre sincronizzata con il codice.
Lo schema viene salvato automaticamente nel localStorage del browser — ritorna alla prossima visita sullo stesso dispositivo. Per condividerlo o portarlo su un altro dispositivo usa l'export JSON o il codice XState e salvalo nel tuo repository.
Il codice XState generato è un punto di partenza valido. Per la produzione aggiungi: guard (condizioni sulle transizioni), action (side effect come fetch o logging) e context (dati associati alla macchina). La struttura degli stati e delle transizioni generata dal tool è già corretta.